Date: Sun, 4 Jul 2004 16:57:58 -0400 (EDT) From: Andrew Gallatin <gallatin@cs.duke.edu> To: Julian Elischer <julian@elischer.org> Cc: Andrew Gallatin <gallatin@cs.duke.edu> Subject: Re: odd KSE panic Message-ID: <16616.28502.692389.458282@grasshopper.cs.duke.edu> In-Reply-To: <Pine.BSF.4.21.0407021443490.8035-100000@InterJet.elischer.org> References: <16613.53106.413179.808734@grasshopper.cs.duke.edu> <Pine.BSF.4.21.0407021443490.8035-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer writes: > When one thread calls exit() it marks the fact that the process is > exiting, and then tries to wakeup all the other threads, and then > suspends itself. The other threads, when awoken are supposed to notice > what's going on and abort whatever they are doing and when they release > all their resources, (by unrolling back to the user boundary) they are > supposed to call thread_exit(). The last one out is supposed to > wakeyup the original thread that called exit(), which can then proceed > on the basis that it is now the only remaining thread. > > If there are threads waiting in uninterruptble sleeps then the process > as a whole can not exit until they have finished sleeping and come back > to the user boundary and called thread_exit(). > > None of the three threads you show is in exit, or even anything related > to exit. > Thank you for this explaination.. The way that threads exit is one of the things I've never understood about KSE. > > ummmm nope.. where is mx_free? > Unreleased 3rd party device driver.. Drew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?16616.28502.692389.458282>