Date: Wed, 24 Nov 1999 17:39:47 -0600 From: "Richard Seaman, Jr." <dick@tar.com> To: Julian Elischer <julian@whistle.com> Cc: freebsd-arch@freebsd.org Subject: Re: Threads Message-ID: <19991124173947.K1408@tar.com> In-Reply-To: <Pine.BSF.4.10.9911241405570.11412-100000@current1.whistle.com> References: <Pine.BSF.4.10.9911241207100.11412-100000@current1.whistle.com> <Pine.BSF.4.10.9911241405570.11412-100000@current1.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Nov 24, 1999 at 02:40:52PM -0800, Julian Elischer wrote: > here are some common points that I think everyone agrees on: > > The proc structure get's broken down to separate out those parts needed > to schedule. (i.e. context etc) This is probably the best. But, if you wanted to start out in a less invasive manner (ie. less kernel changes), I don't know why the KSE couldn't be an rforked proc (with appropriate flags), with only minor changes to the proc structure (eg. you might need to hold a pointer to the UTS, though if your "upcall" was just a signal, maybe the pointer to the UTS could be a signal handler). In this case your KSE would be "heavier", in terms of kernel context, than you would really need, but hopefully you wouldn't need all that many of them (one for each processor plus one for each thread blocked in a syscall, plus maybe a few more if you need more scheduler classes for your thread pool). The aio kernel code manages a pool of "kernel threads" that might provide a template for how to manage a pool of KSE's in this manner. Doing this might get you up and running sooner, with a longer term goal of reivsing the proc structure more extensively. Just a thought. -- Richard Seaman, Jr. email: dick@tar.com 5182 N. Maple Lane phone: 262-367-5450 Chenequa WI 53058 fax: 262-367-5852 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?19991124173947.K1408>