Date: Sun, 31 Oct 1999 20:02:36 -0700 From: Nate Williams <nate@mt.sri.com> To: Julian Elischer <julian@whistle.com> Cc: Nate Williams <nate@mt.sri.com>, Daniel Eischen <eischen@vigrid.com>, freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. Message-ID: <199911010302.UAA14279@mt.sri.com> In-Reply-To: <Pine.BSF.4.05.9910311841320.8816-100000@home.elischer.org> References: <199911010219.TAA13936@mt.sri.com> <Pine.BSF.4.05.9910311841320.8816-100000@home.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > 11.) Ability for the threads library to cancel/terminate a thread > > > > blocked in the kernel. > > > > > > oooooh > > > > Oooh is right. This has the potential to deadlock the kernel if the > > thread owns some sort of 'thread' resources. Justin and I were having a > > discussion about this very thing earlier today, and I don't think I was > > able to express myself well, so here it goes again. > > > > Basically, what happens if a particular thread owns a resource that > > others are blocking on, and it's woken up 'prematurely'? If the thread > > is aborted out of the kernel, the other threads (which might exist in > > the kernel) may not be woken up (ever), thus causing zombie threads. > > I think what is being asked for is the thread version of the > signal catching capabilities of the present tsleep(). > The situation is no worse than it is at present. Sort of, except that for every process you can only have one thread in kernel space, so the only deadlocks that can occur happen in userland, since the kernel has no primitives for doing 'synchronization' and notification. (Unless you consider the SysV stuff, but as we've seen, people tend to screw up using that as well. :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199911010302.UAA14279>