Date: Tue, 30 Nov 1999 10:41:51 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: "Daniel M. Eischen" <eischen@vigrid.com> Cc: Julian Elischer <julian@whistle.com>, arch@freebsd.org Subject: Re: Threads stuff Message-ID: <199911301841.KAA26600@apollo.backplane.com> References: <Pine.BSF.4.10.9911282113490.544-100000@current1.whistle.com> <384270AE.D0250340@vigrid.com> <38440BAB.E547CA61@vigrid.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I think implementing a threading mechanism in the kernel is going to be
a whole lot easier then implementing async call gates. In fact, the
whole KSE mechanism is going to be easier to implement if they are
integrated into a native kernel-based threading mechanism. If you
*don't* do that, you *still* have to implement 80% of a kernel-based
threading mechanism simply to be able to manage the KSE's, and so far
I've heard half a dozen other special cases come up as being 'absolutely
necessary' to prevent screwups. Frankly, when people talk about upcalls,
wiring user memory, and controlling blocked kernel-mode KSEs from a user
program... it *scares* me.
I can implement kernel KSE's with an integrated kernel thread mechanism
in a week, but I'm not going to do it unless I have a reasonable assurance
that I can commit it :-). Most of the ground work has already been
accomplished -- it became easy to do the moment the kernel stack was
moved out of the common VM share.
If we did things this way, I guarentee you that implementing a UTS will
become trivial, without *any* special cases. In fact, it could be done
without any upcalls either. A simple event reporting mechanism and a
management thread to handle the everyone-is-asleep case is all you need.
-Matt
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?199911301841.KAA26600>