Date: Sun, 01 Nov 1998 23:29:39 +0800 From: Peter Wemm <peter@netplex.com.au> To: Daniel Eischen <eischen@vigrid.com> Cc: lists@tar.com, current@FreeBSD.ORG, jb@cimlogic.com.au Subject: Re: Kernel threading (was Re: Thread Scheduler bug) Message-ID: <199811011529.XAA25055@spinner.netplex.com.au> In-Reply-To: Your message of "Sun, 01 Nov 1998 08:38:39 EST." <199811011338.IAA02419@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Daniel Eischen wrote: > Richard Seaman, Jr. wrote: > > On Sat, 31 Oct 1998 14:08:43 -0800, Jordan K. Hubbard wrote: > > > > >I agree. While not perhaps adopting the perfect approach, at least > > >Richard brings some very welcome *movement* to an issue which has been > > >stalled for a regrettably long period of time. Let's try to run > > >(cooperatively) with this and hopefully arrive at some working, > > >architecturally clean kernel threads for FreeBSD! > > > > Just to be clear. I'm happy to co-operate and share code with anyone. > > In fact, I'd be happy for someone else to just handle it all. In the > > absence of someone else will to handle it all, I'm happy to contribute > > what I can. > > > > The *only* reason I'd be hesitant to share any code at this moment > > is that its still pretty messy, and I'd be embarrassed, and since > > its barely tested, people would rightfully shoot all kinds of holes > > in it. When its in a better state I'd be happy to post it somewhere > > where anyone can whack at it. > > > > I'd like to help in this effort, but I'd first like to see > exactly what threading model is desired. Do we want a Solaris > lightweight process model with the ability have both bound > and unbound user threads? Or do we want libpthread to keep > a one-one mapping of threads to kernel threads? I'm not familiar with Solaris threads but have seen the man pages for the SVR4.2-whatever-it-is-this-week as used in Unixware. What I had in mind was something along the lines of: - the kernel context switching entity would become a 'thread' rather than a 'proc'. - a "process" (struct proc) would have one or more threads, all using the same address space, pid, signals, etc. - The logistics of doing this are ugly. I don't expect that a global 's/sturct proc/struct thread/g' would go down well. - the boundaries between the present 'struct proc', pcb, upages, etc would get muddied a bit in the process. The context that a thread would need would be something like a superset of the pcb at present. - A thread would have just enough context for making syscalls etc. - context switching between threads would be bloody quick, as good or better than switching between rfork shared address space siblings. - There would be one kernel stack per thread, up to a limit of the number of present CPU in operation. If you had 4 cpus and 1000 threads, you still only need 4 stacks and other associated things (PTD etc). - It would be nice to have some sort of cooperative kernel<->user scheduling interface so that it would be possible to have the libpthread "engine" schedule it's pthreads onto kernel threads. Suppose one wants a few thousand pthreads, but only realistically needs 10 or 20 of them to block in syscalls at any given time. I'd love to get more involved in this from the kernel side of this, but surviving from day to day is number one priority at the moment. Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199811011529.XAA25055>