Re: L4Hurd at Sourceforge

[Farid Hajji]

> On Tue, Oct 23, 2001 at 02:59:33AM +0200, Farid Hajji wrote:
> > Unfortunately, the Hurd sources themselves use C-Threads. However, they
> > use them only in a few places. I see no reasons why those few calls can't
> > be changed to Pthreads calls (with macros?) even now in the Hurd sources.
[snip]
> Pthreads is a little bit more complicated. We need to rewrite parts of
> libc to support it, especially the signalling code (at least this is
> what I've read, I'm still busy finding my ways in the current pthreads
> code). The pthreads code will be a generic pthreads implementation in
> glibc, for Mach/Hurd, L4/Hurd but also Linux and other kernels.
> The pthreads code in oskit is not a full implementation, just a subset.
I don't know what pthreads code you mean here. If you mean something
like LinuxThreads, forget about it! Lightweight duplication of a process
with clone() is linux specific and not compatible to anything else in
the world. If someone plans to build pthreads code in glibc on top of
that, it would be 100% incompatible to any other kernel, including Mach!.

Sure, pthreads code and the rest of the c-library (be it glibc or any
other c-library like OSKit's FreeBSD libc or anything else) need to be
synchronized w.r.t. signalling code. I don't know how reentrant glibc
happens to be in other parts either...

As far as the Hurd/L4 port is concerned, we need at least the following:
  * change calls to c-threads with calls to p-threads (as I've said before),
  * a working pthreads library running on top of Mach (be it with macros
    to c-threads or be it a true, full-blown pthreads library),
    for the migration,
  * a working pthreads library running on top of L4 (probably a 1:1-type
    of library that will rely on L4 to provide enough kernel threads)
  * a thread-safe + [p]thread-aware C-library (be it glibc, libc or anyting
    else).
  * a thread-aware IDL generator in the sense that it will use pthreads
    (or possibly L4-threads directly) in the stubs/skeletons where necessary.

Currently, the issue of p-threads is not yet very urgent, but we won't
make significant progress later without it.

> The current code is in the hurd sourceforgetit CVS (created before
> sourceforge went proprietary). I don't have an account there, however I
> have just made a savannah account. If we start a project for l4-hurd at
> savannah, should I include the pthreads code there? (it won't go into
> the official glibc before it's finished and that takes some time). Or
> should I start an own project for pthreads?=20
Let's listen to L4 folks concerning pthreads. Do they plan to provide
pthreads support for L4 themselves, would they rely on OSKit or should
we adapt a _good_ pthreads library to use L4 threads ourselves? I don't
know.

> Jeroen Dekkers

-Farid.

-- 
Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555
Broicherdorfstr. 83, D-41564 Kaarst, Germany  | address@hidden
- - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - -
One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates.