Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!pt.cs.cmu.edu!spice.cs.cmu.edu!af From: af@spice.cs.cmu.edu (Alessandro Forin) Newsgroups: comp.os.mach Subject: Re: cthread_exit Summary: caching Message-ID: <10282@pt.cs.cmu.edu> Date: 17 Aug 90 13:56:58 GMT References: Distribution: usa Organization: Carnegie-Mellon University, CS/RI Lines: 23 In article , 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-