At Sun, 25 Sep 2005 23:10:46 -0400, "Jonathan S. Shapiro" <[EMAIL PROTECTED]> wrote: > A few days ago, Marcus Brinkmann mentioned that the Hurd is likely to > move toward the NPTL thread model. From the context of our conversation, > I *assume* that he meant "... for native-mode Mach execution". When > running a POSIX environment one must of course implement pthreads.
The Hurd does not include any native-mode Mach execution. It currently only has one personality, and this is the GNU/Hurd personality, which includes glibc and thus a full POSIX environment. I do not dare to speak of the native Hurd server interfaces as of a full environment. It is more or less designed around the requirement to implement the extended POSIX environment on top of it. > NPTL is conceptually feasible for Mach because the Mach kernel has a > "threads within processes" process model. This is not true in Coyotos, > and we urgently need to understand if this requires an architectural > re-examination of assumptions. The Coyotos model is closer in spirit to > the LinuxThreads model, wherein threads are co-equal processes with some > shared state. I do not think this is an issue at all. NPTL was designed and written for the Linux kernel, and the Linux kernel uses a one-thread per process model using the clone system call. It is true however that with NPTL the Linux kernel got some extensions to allow to implement the thread library with less fuzz. So, maybe the current Linux model is better described as a one-thread-plus-a-little-something per process mixed design. > ** Question for Neal and Marcus: what is the motivation for taking > Mach/Hurd to NPTL, and does the motivation carry over to Coyotos? The main reasons are: * Let other people do the work. If the shared parts of NPTL are designed and maintained by somebody else, than we can spend our time on other stuff. * Let other people do the work. If we use the same thread library as GNU/Linux, applications will be easier portable because the assumptions they make are fit by our system as well as by GNU/Linux. Currently we use cthreads and a pthread library written by Neal. However, both is a maintenance burden when porting applications. > As I understand matters, three issues motivated the move to NPTL in > Linux. In each case, the LinuxThreads behavior could not easily be > reconciled with the requirements of pthreads: > > 1. Signal delivery and blocking > 2. Behavior of exec() > 3. pthreads broadcast operations > > Does anybody know of any others? "The Native POSIX Thread Library for Linux" article by Ulrich Drepper has some more reasons: * LinuxThreads has a manager thread which is causing problems, because the manager thread can be accidentially killed, leaving the process in a state which requires manual clean-up. My response to this would be that in a microkernel operating system, we will definitely need a manager thread anyway to emulate pre-emptive event notification. * The use of signals to implement synchronization primitives, which is inefficient and error prone. My response: Note that Linux got a futex (fast mutex) system call to solve this. Either kernel primitives are needed, or the messaging system must be used to implement synchronization primitives using a manager thread. As a border-case, also consider shared mutexes between processes with a restricted trust relationship. * If you have one process per thread, threads have different process IDs, which can cause compatibility problems with other pthread implementations. My response: No problem for us, because process IDs need to be emulated anyway. Drepper also mentions some problems on the kernel side: * Hundreds or thousands of threads make the /proc filesystem unusable. My response: No /proc filesystem in the kernel, but still process listing and process management could cause user interface issues that must be addressed. * Signals like SIGSTOP require special kernel support (in Linux). Then Drepper goes on and elaborates on the requirements for the new NPTL design, which is quite a hefty list. http://people.redhat.com/drepper/nptl-design.pdf Marcus _______________________________________________ coyotos-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/coyotos-dev
