Path: utzoo!censor!geac!jtsv16!uunet!cs.utexas.edu!uwm.edu!gem.mps.ohio-state.edu!rpi!ander
From: ander@pawl.rpi.edu (Michael R. Primm)
Newsgroups: comp.os.os2
Subject: Re: signals, threads, and memory allocation
Message-ID: <1989Nov10.160424.6387@rpi.edu>
Date: 10 Nov 89 16:04:24 GMT
References: <32295@ucbvax.BERKELEY.EDU> <8551@microsoft.UUCP> <1989Nov10.025654.3274@eddie.mit.edu>
Organization: Rensselaer Polytechnic Institute, Troy NY
Lines: 14


One problem with emulating the fork(2) idea of "resurrecting" old thread
cadavers is that threads should never have cadavers in the first place.
The whole distinction between a thread and a child process is that a thread
shares EVERYTHING with its fellow threads  Therefore,  OS/2 processes
don't spin off copies of themselves (and their data areas) when a new thread
is created, only a new context is created.
In any case, I do like having the option of controlling the threads at a 
low level (just handing the thread a stack and starting it has got to be
faster than having the operating system allocate the space, start the thread,
and remember to deallocate the space after the thread dies).  BUT, I think 
such an option would have been very helpful, given the likely frequent use of
such a feature.
                                                    --Mike Primm