Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!umd5!cvl!elsie!nih-csl!keith
From: keith@nih-csl.UUCP (keith gorlen)
Newsgroups: comp.lang.c++
Subject: Re: OOPS gripes (was: Generic Object Or
Message-ID: <305@nih-csl.UUCP>
Date: 4 Feb 88 14:32:04 GMT
References: <303@nih-csl.UUCP> <4800013@uiucdcsm>
Organization: NIH-CSL, Bethesda, MD
Lines: 50
Summary: I'd be willing to look into replacing OOPS Processes with
	 a reasonably portable, public domain implementation of threads.

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 20892