Newsgroups: comp.archives
Path: utzoo!utgpu!news-server.csri.toronto.edu!math.lsa.umich.edu!math.lsa.umich.edu!emv
From: af@spice.cs.cmu.edu (Alessandro Forin)
Subject: [comp.os.mach] Re: cthread_exit
Message-ID: <1990Aug17.145734.2680@math.lsa.umich.edu>
Followup-To: comp.os.mach
Sender: emv@math.lsa.umich.edu (Edward Vielmetti)
Reply-To: af@spice.cs.cmu.edu (Alessandro Forin)
Organization: University of Michigan, Department of Mathematics
Date: Fri, 17 Aug 90 14:57:34 GMT
Approved: emv@math.lsa.umich.edu (Edward Vielmetti)
X-Original-Newsgroups: comp.os.mach
Lines: 30

Archive-name: mach-gdb/17-Aug-90
Original-posting-by: af@spice.cs.cmu.edu (Alessandro Forin)
Original-subject: Re: cthread_exit
Archive-site: wb1.cs.cmu.edu [128.2.250.16]
Archive-directory: /usr/mach/public/source
Reposted-by: emv@math.lsa.umich.edu (Edward Vielmetti)

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-