[comp.os.mach] cthread_exit

swfc@cs.columbia.edu (Shu-Wie F Chen) (08/13/90)

I am writing a server that forks off threads to handle requests.  Each
(detached) thread executes a procedure whose last call is to
cthread_exit.

With DEBUG defined and cthread_debug = TRUE, I get messages that say
the threads are exitting and done.  However, if I do a ps -m, I still
see threads lying around.  What's going on?

Thanks.

*swfc
-------------------------------------------------------------------------------
Shu-Wie F Chen	             Columbia University Department of Computer Science
swfc@cs.columbia.edu	     500 W120th Street, New York, NY 10027
--
-------------------------------------------------------------------------------
Shu-Wie F Chen	             Columbia University Department of Computer Science
swfc@cs.columbia.edu	     500 W120th Street, New York, NY 10027

bsy+@cs.cmu.edu (Bennet Yee) (08/17/90)

The distinction is between the kernel's idea of threads and cthreads' idea
of threads.  When you do a cthread_exit, cthreads do not actually terminate
the thread; rather the cthreads package keeps the thread around (idle) for
the next time you do a cthread_fork.

-bsy


--
Bennet S. Yee, +1 412 268-7571
School of Cucumber Science, Cranberry Melon, Pittsburgh, PA 15213-3890
Internet: bsy+@cs.cmu.edu		Uunet: ...!seismo!cs.cmu.edu!bsy+
Csnet: bsy+%cs.cmu.edu@relay.cs.net	Bitnet: bsy+%cs.cmu.edu@cmuccvma

af@spice.cs.cmu.edu (Alessandro Forin) (08/17/90)

In article <SWFC.90Aug12135243@mendelssohn.cs.columbia.edu>, swfc@cs.columbia.edu (Shu-Wie F Chen) writes:
> 
> ..the threads are exitting and done.  However, if I do a ps -m, I still
> see threads lying around.  What's going on?
> 

C-threads and kernel threads do not necessarily have to match one to one.
Indeed, what you are seeing is the official implementation keeping kernel
threads around to speed up future C-threads creations.

There is another implementation, which we use in the single-server U*x
emulation, which arbitrarily maps N C-threads into M kernel threads
giving you at runtime any behaviour from the coroutine-like to the
fully parallel one.

Soo, ps(1) is not necessarily a good eye for looking at C-threads.  What
people use around here is a version of GDB that understands enough of the
C-threads internals to let you see more properly your C-threads based
application, and debug it with some more appropriate tools.
If you are interested, you can FTP it anonymous from wb1.cs.cmu.edu, in
/usr/mach/public/src/gdb.3.5.Z.

sandro-