Date: Wed, 16 Dec 98 07:52:55 -0600 From: "Richard Seaman, Jr." <lists@tar.com> To: "Archie Cobbs" <archie@whistle.com> Cc: "current@FreeBSD.ORG" <current@FreeBSD.ORG> Subject: Re: Linux Threads patches available Message-ID: <199812161352.HAA11221@ns.tar.com>
next in thread | raw e-mail | index | archive | help
On Tue, 15 Dec 1998 15:57:35 -0800 (PST), Archie Cobbs wrote: >Richard Seaman, Jr. writes: >> Earlier I offered >> to try to implement a "one-to-one" kernel threads library by extending >> the current pthreads code, but almost all the comments I received were >> that people wanted something other than one-to-one kernel threads. >> This was beyond my capabilities and interest. > >Forgive me if I don't completely understand, but... You probably understand it all better than I do. I'm still learning :) >It seems that if the one-to-one implementation were layered the >right way, it would be easy to add a 'shim' layer (later on) that >converts it into a many-to-many version of the same thing. As I posted a while back, a lot of the existing FreeBSD pthreads code could be made "generic", interfacing to just a few functions in what you refer to as the "shim layer". However, each time I've tried to design what these functions should look like, I end up concluding that a decision needs to be make about the design of the threads implementation(s) the "shim layer" would be dealing with. Since I'm not sure what the design of a "many to many" threads would look like, I've put off the project. >In other words, can't you localize the operation 'give me a new >context' to a single place in the code, which to start with always >creates a kernel thread, but later can do some more intelligent >thread management? Sure. Actually, this part of the existing pthreads code is already pretty localized, and could be made somewhat more so. My problem in designing generic pthreads code revolves around a few issues that might vary greatly depending on how the threads are implemented. These include: 1) How do you handle syscall blocking? I'd guess that 50-75% of the existing pthreads code is dedicated to dealing with syscall blocking. If we can know for sure what the "many to many" implementation will do, then coding the pthreads code for either a "one to one" or a "many to many" can proceed logically. 2) How will thread sleep/wakeup (or in linux suspend/restart) be implemented? How will the code handle the "lost wakeup" problem that potentially exists in the mutex and cond routines? How will the sleep/wakeup routines deal with thread cancellation? 3) How will thread cancellation be implemented? 4) What will the signal handling code look like? Will signals be used in the sleep/wakeup routines, in thread cancellation, or for thread preemption? Where is signal delivery handled (kernel vs. user or mixed) in the many/many case? Will signal handling be fully posix compliant, and what additional kernel changes will be made to get us there? 5) How is pthread_exit and thread cleanup processing handled? And, a related question, where is thread creation handled? Does one have a "thread manager thread" that is the parent of every kernel thread entity? There are other issues, but these strike me as the main ones. There are solutions to all these issues, but each time I look at them, I feel the need to design the "many-many" implementation first before proceeding. 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?199812161352.HAA11221>