Date: Sun, 31 Oct 1999 21:12:32 -0700 From: Nate Williams <nate@mt.sri.com> To: Daniel Eischen <eischen@vigrid.com> Cc: julian@whistle.com, nate@mt.sri.com, freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. Message-ID: <199911010412.VAA14975@mt.sri.com> In-Reply-To: <199911010347.WAA20149@pcnet1.pcnet.com> References: <199911010347.WAA20149@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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. :) > > No, I want to be able to have multiple threads in a single process > be in kernel space. Only one can be running, but others can be > blocked. Agreed. My point is that if we allow multiple threads in a single process in the kernel space, it's alot worse than the present tsleep issues.... 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?199911010412.VAA14975>