l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: L4Hurd at Sourceforge


From: Jeroen Dekkers
Subject: Re: L4Hurd at Sourceforge
Date: Wed, 24 Oct 2001 01:54:44 +0200
User-agent: Mutt/1.3.23i

On Tue, Oct 23, 2001 at 08:49:27PM +0200, Farid Hajji wrote:
> > 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!.

No, an implementation started by Mark Kettenis. Mark hasn't finished it
however, Igor Khavkine picked up and wrote some things but he doesn't
have the time to finish it either. Now am I picking it up, together with 
Ryan Golbeck. It was writtin to be put in glibc and portable. Only some
very small changes in the sysdeps are needed to get it working on L4
when it works on Mach/Hurd. The current code is at sourceforge hurd
project, I don't have an account there however. I'm registered a
savannah project for it and I'm waiting for the confirmation. I will
post a message as soon as it is available there.

> 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...

I don't know what you mean with "synchronized w.r.t. signalling code."
Glibc is fully reentranti however.

> 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)

See below for an explanation.

>   * a thread-safe + [p]thread-aware C-library (be it glibc, libc or anyting
>     else).

That will be glibc if you ask me, I don't see any point in using another
library.

>   * a thread-aware IDL generator in the sense that it will use pthreads
>     (or possibly L4-threads directly) in the stubs/skeletons where necessary.

I don't see why a stub should even know about threads, it only needs to
be reentrant.

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

The hurd is heavily multithreaded, it is important as soon as you're
going to start with porting the hurd itself.

> > 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.

Roland has said some things about pthreads here (I assume he's right).
http://mail.gnu.org/pipermail/bug-hurd/2001-May/004317.html
http://mail.gnu.org/pipermail/bug-hurd/2001-July/004782.html

The L4 specific parts are so small it's easy to write. However, there is
also the signalling code to be dealt with and on which pthread_cancel
(an important function) depends. This will be necessary sooner or later
anyway, having it is just only better. I'm now going to dig into the
glibc signalling code and fix everything that needs to be fixed. 

This pthreads implementation will run on L4 and mach (and on other
kernels if somebody adds sysdeps), so we can convert the hurd to
pthreads and fully abandon cthreads. This code will be in the glibc code
then.

Jeroen Dekkers
-- 
"all the _really_ interesting stuff will be going on in user space."
        --Linus Torvalds
"just say NO TO DRUGS, and maybe you won't end up like the Hurd people."
        --Linus Torvalds, "I was never a "big thinker""

Attachment: pgpmrJvTtXqgq.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]