keith@nih-csl.UUCP (keith gorlen) (01/30/88)
>Nf-From: uiucdcsm.cs.uiuc.edu!grunwald Jan 28 00:01:00 1988 > >Can we gripe about OOPS in here? I'd like some general feedback from others >who use OOPS. > >1) I think that the OOPS names should be more long-winded for internal > functions. I'm mainly thinking of 'release'. > > I've got a set of routines for OOPS/Extentions for a Discrete Event > Simulation Evenvironment (OOPS/EDASE), and 'release' as a very different > meaning in simulation programs. > > 'releaseInternalObjects' might be better. I just used Smalltalk-80 names for similar functions in OOPS. The whole dependent objects business doesn't work out that well in OOPS anyway. Since there isn't garbage collection, it's difficult to know when to delete dependent objects. Maybe the whole mechanism should be removed, or at least re-thought out. >2) There's too much of a tie-in to the provided 'process' notion -- it should > be possible to not have the Exception stuff loaded. I'm using a thread > notation which is cheaper than the process notation, primarily because > it's designed for DAS, where I don't use any exceptions. > Not sure what you mean by this. If you don't use the Process, Semaphore, SharedQueue, Scheduler classes, I don't think anything to do with them gets loaded -- at least that was the intent. The Exception stuff is a failed experiment, in my opinion. It's too difficult to use and error-prone. Exception handling really needs to be added to C++ to do this right, so this is another thing that could be removed from OOPS. >dirk grunwald >univ. of illinois -- Keith Gorlen phone: (301) 496-5363 Building 12A, Room 2017 uucp: uunet!ncifcrf.gov!nih-csl!keith National Institutes of Health Internet: keith%nih-csl@ncifcrf.gov Bethesda, MD 20892
grunwald@uiucdcsm.cs.uiuc.edu (02/04/88)
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.
keith@nih-csl.UUCP (keith gorlen) (02/04/88)
In article <4800013@uiucdcsm>, grunwald@uiucdcsm.cs.uiuc.edu writes:
->
-> 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.
My inclination is to ignore the OOPS exception handling code as much
as possible, and replace it when exception handling is incorporated
into C++.
-> 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.
Our biggest problem with Processes is that using them breaks the debugger
on Suns. Does your model fix this problem?
-> 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.
Does your implementation allow a thread to block on multiple
Semaphores, and be unblocked when ANY of them receive a signal? This
is another feature we could use in OOPS.
This all sounds very interesting. How can I get more details?
-> 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.
Is Brown's stuff public domain? Can you give me some pointers?
--
Keith Gorlen phone: (301) 496-5363
Building 12A, Room 2017 uucp: uunet!ncifcrf.gov!nih-csl!keith
National Institutes of Health Internet: keith%nih-csl@ncifcrf.gov
Bethesda, MD 20892norman@a.cs.okstate.edu (Norman Graham) (02/07/88)
in article , keith@nih-csl.UUCP (keith gorlen) says: > My inclination is to ignore the OOPS exception handling code as much > as possible, and replace it when exception handling is incorporated > into C++. Oh joy! You mean C++ will soon have exception handling? I can't believe it (Pinch, Pinch :-)! I tried desperately to design a suitable (ie. simple, transparent, etc) exception handling scheme for a project I'm involed with ( >80000 lines of C source in >450 files). We wanted to use a stack of exception frames and we would have, except for one problem... we couldn't guarentee that the exception frame stack would be poped on each function return. Of course, it is easy for a compiler to do this. (Guess what we ended up with... returning a status from each function!!! Yuch!) -- Norman Graham Oklahoma State University Internet: norman@a.cs.okstate.edu Computing and Information Sciences UUCP: {cbosgd, ihnp4, 219 Mathematical Sciences Building rutgers}!okstate!norman Stillwater, OK 74078-0599