Date: Sat, 7 Mar 1998 22:55:10 -0700 From: Nate Williams <nate@mt.sri.com> To: John Birrell <jb@cimlogic.com.au> Cc: nate@mt.sri.com (Nate Williams), cvs-committers@FreeBSD.ORG Subject: Re: cvs commit: src/lib/libc_r/uthread pthread_private.h uthread_yield.c Message-ID: <199803080555.WAA06789@mt.sri.com> In-Reply-To: <199803080549.QAA10989@cimlogic.com.au> References: <199803080536.WAA06540@mt.sri.com> <199803080549.QAA10989@cimlogic.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
[ Kernel thread being 'heavyweight' ] > > It seems to me we're checking off a box on someone's list of features > > w/out any regard to the usefulness of that feature. :( > > Yes, in the short term that's sort of true. Most of this is John Dyson's > work, so I'll ask him to correct me if I'm wrong. I believe it's a > case of learning to walk before learning to run. We all know about the > work that John has been doing to the VM. This includes support for > kernel threads. The simplest method of attack was to keep the kernel > threads like processes so that the VM side of things could be proven > to be stable. Then, with a stable VM, work could progress on pruning > kernel threads down so that things like signal handling would only > work at process level (like POSIX says), and not at individual thread > level. It'll require changes to the way things are scheduled and processes > forked. Fair enough, but it seems that a stable VM would be tested just as well with normal processes, so why the need for heavyweight 'threads'? > In the long term, kernel threads will be more than just a > check-in-a-box, IMHO. Good enough. After using threads consistently for about 18 months, I *like* them, but understand that if they become too heavy, most of the advantages of using them go away. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199803080555.WAA06789>