Article View: comp.os.os2
Article #159Re: signals, threads, and memory allocation
From: Michael R. Primm
Date: Fri, 10 Nov 1989 16:04
Date: Fri, 10 Nov 1989 16:04
14 lines
1349 bytes
1349 bytes
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
Technical Details
Message-ID:
<1989Nov10.160424.6387@rpi.edu>Path:
arc1-ca.pugleaf.net!utzoo!censor!geac!jtsv16!uunet!cs.utexas.edu!uwm.edu!gem.mps.ohio-state.edu!rpi!anderReferences:
<32295@ucbvax.BERKELEY.EDU> <8551@microsoft.UUCP> <1989Nov10.025654.3274@eddie.mit.edu>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!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