af@spice.cs.cmu.edu (Alessandro Forin) (08/17/90)
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-