🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.os.os2
Article #159

Re: signals, threads, and memory allocation

#159
From: Michael R. Primm
Date: Fri, 10 Nov 1989 16:04
14 lines
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!ander
References: <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