Re: pthreads imported to the Sourceforge CVS
> I have a couple of questions then. The code relies heavily on the
> use of __spin_lock operations, however they are mach specific.
Only __spin_lock_solid is actually Mach-specific, and that only in its
implementation and not its interface. Other kernels might too have a
"yield time" system call that's appropriate. Or you could fall back to a
machine-dependent busy loop (e.g. linuxthreads/sysdeps/i386/pspinlock.c) or
a generic one.
> Is there a standard internal iterface to locks in glibc?
There are a few approximations, e.g. atomicity. You should steal freely from
the linuxthreads source files that say copyright Free Software Foundation (but
not the ones copyright Xavier Leroy). Much of that stuff, such as the
pspinlock.c implementations for all those machines, can just be folded in as
generic glibc implementation facilities that subsume previous
libc/linuxthreads and libc/hurd internal facilities (either renamed to be less
pthread- or linuxthreads-specific, or just used as is).
> Otherwise most of the code already has to be moved into under sysdeps/mach.
That doesn't make sense. Please elaborate.
> Also what is the difference between sysdeps/generic/ and pthread/
> subdirs. They both contain system independent code.
* sysdeps/generic contains wholly generic code, and ENOSYS stubs.
What "wholly generic" usually means is that it is implemented in terms of
pure C/machine functionality and not using the OS.
* sysdeps/CPU contains wholly generic machine-dependent code, i.e.
nothing that wouldn't go into sysdeps/generic except for using pure
hardware features always available in user mode
* sysdeps/pthread contains code that (in theory) is implemented purely in
terms of the standard <pthread.h> interfaces
* sysdeps/posix contains code that works is implemented purely in terms of
the POSIX.1 functions (1003.1-1990, more or less, i.e. no newfangled
-1996 options like pthreads et al), that is your basic file descriptors,
fork, exec, so forth.
Reply to: