Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!umd5!purdue!i.cc.purdue.edu!j.cc.purdue.edu!pur-ee!uiucdcs!uiucdcsm!grunwald
From: grunwald@uiucdcsm.cs.uiuc.edu
Newsgroups: comp.lang.c++
Subject: Re: OOPS gripes (was: Generic Object Or
Message-ID: <4800013@uiucdcsm>
Date: 3 Feb 88 18:08:00 GMT
References: <303@nih-csl.UUCP>
Lines: 29
Nf-ID: #R:nih-csl.UUCP:303:uiucdcsm:4800013:000:1413
Nf-From: uiucdcsm.cs.uiuc.edu!grunwald    Feb  3 12:08:00 1988


I don't what to be misconstrued as whining about OOPS -- I think it's great.
This is the ``user feedback'' from a avid user.

The comments about the exception stuff being tied in stems from the code 
which uses setOOPSerrors, which ties in the exception code & the exceptact
code.

The process model is O.K, by & large, but it's not terribly robust.
I've redone the model to use threads, which don't use the exception package
and which do stack bounds checks (on each context switch). In addition, they
preserve the floating point registers.

Part of the problem with the 'Process' model is that is make some assumptions
concerning the target architecture. It needs to save the SP (e.g. for the
Encore Multimax, and other NS32032 machines).

Also, it's possible (maybe not desireable) to have a THREAD_FORK in any
routine, not just the initializer. Another change is that there isn't a
reliance on a single Scheduler. Schedulers are ThreadContainers, as is
'Cpu' -- the abstraction for the machine state.

This lets you bind a variety of different schedulers to TheScheduler, the
system level scheduler. For example, I bind an EventSchduler to TheScheduler,
but for Semaphores (& Barriers), I use FifoSchedulers.

Actually, I'm about to consider scrapping the thread stuff I've got & using
the threads package from Brown -- They've got hooks for multi-processing
for Encore's & simulation of the same under Suns.