Skip site navigation (1)Skip section navigation (2)
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>