GNU/Hurd Gets POSIX Threads

An anonymous reader writes "Neal Walfield announced the first release of RMGPT, which is (or rather, aspires to one day be) a complete, portable implementation of IEEE Std 1003.1-2001 threads also known as POSIX threads. With this new pthreads library, it will soon be possible to run complex software packages on the Hurd, including the GNOME and KDE desktops, the OpenOffice suite, and the Mozilla web browser. Find more information here, including the humorous meaning behind RMGPT, and insight into a future Hurd release..."

Comments

an excerpt

[Anonymous Coward]

here's an excerpt:

Neal Walfield [interview] announced the first release of RMGPT, which "is (or
rather, aspires to one day be) a complete, portable implementation of IEEE Std
1003.1-2001 threads [also] known as POSIX threads." I was excited to read Neal's
announcement email, as this is a big step forward for the GNU/Hurd project. With this
new pthreads library, it will soon be possible to run complex software packages on the
Hurd, including the GNOME and KDE desktops, the OpenOffice suite, and the Mozilla
web browser.

Regarding the name, RMGPT, Neal explains, "Most new program names are a bunch
of letters stuck together. Only later does it become an acronym and the words
become bound. This is boring; each new release of RMGPT will offer a fresh, new and
exciting expansion of the 'acronym'." For this first release, RMGPT stands for
"Rubbish, I asked for mine with Minced Garlic, Please Take this back".

Neal was kind enough to answer a few questions about his pthread efforts. Read on to
learn more...

JA: What does this first release of a POSIX threads implementation mean for the
GNU/Hurd project?

Neal Walfield: Beyond adding another important, commonly used interface, I think
that a pthread implementation represents a large step forward in the public eye: we
should soon have many more major software packages including GNOME, KDE,
OpenOffice and Mozilla. The perceived lack of support for complex software was
often assumed to be a result of a general lack of maturity on the part of the Hurd itself.
In certain respects, this is correct: until now, there was no pthread implementation;
there are still limits on the maximum size of file systems; and Mach only supports a
limited amount of hardware. On the other hand, the Hurd was not designed to just
clone an existing interface; the goal was to study what was available, explore the
flaws and then redesign it. From this perspective, I think that Hurd has been very
successful: the translator concept is incredibly powerful and flexible; and security
wise, Unix just cannot compete.

JA: You say that RMGPT aspires to one day be a complete, portable implementation
of IEEE Std 1003.1-2001 threads, also known as pthreads. How complete is it today?

Neal Walfield: With respect to the pthread interface, all of the prototypes are present;
implementation wise, I think that we are about ninety percent done. The last ten
percent consists of advanced scheduling features (e.g. mutex priority ceilings) and
process shared resources (the ability to share, for instance, a mutex between multiple
processes just using shared memory). Neither of these are terribly important from a
usability perspective as not many applications take advantage of them, however, I am
interested in implementing them. I think that the ABI should remain stable. I am
relatively confident that the data structures are flexible and expandable enough to
cover most future changes.

There are also bugs, however, the implementation seems to be relatively stable under
normal application load. Several people have compiled some different packages over
the past few days and they seem to be crashing of their own accord, not pthreads'.

JA: How long before you expect RMGPT to be fully completed?

Neal Walfield: The goal right now is to stabilize and get some people to test the code.
Then we can concentrate on finishing the scheduling and process shared attributes
and worry about optimizations. It should be integrated into the Debian unstable system
some time this week. Applications will follow.

JA: How did you come up with the ever changing acronym RMGPT?

Neal Walfield: Take, for instance Perl and UVM: the authors are victims of their own
genius: even though they stated that the name did not mean anything in particular,
people have tried to guess what their real intentions were thus, de facto interpretations
have come into use. I am blatantly telling everyone that it RMGPT will have a new
meaning every release: life does not get any simpler. Plus, it will be less stress for the
users.

JA: How close now would you estimate the GNU/Hurd is for another official release?

Neal Walfield: Getting closer everyday. In fact, I hope that by this time in October,
we will be a whole month closer.

Re:My apologies to RMS

[jbailey999]

The core design of the Hurd still isn't in use by any Free OS out there. The idea is to have as much as possible sit in userspace, and to have "translators" that allow any user to add hooks into the filesystem (making cool things like ftpfs and nfs possible without requiring root, and without requiring the sysadmin to install it for you).

If you're interested, take a look at Towards a New Strategy of OS Design - It explains what we're doing different with the Hurd, and what the core servers are used for.

Tks,
Jeff Bailey

The link is /.ed

[smallpaul]

Here is another one

Hurd is a multi-server

[Per Abrahamsen]

The idea of a microkernel is to have multiple seperate servers running on top of it, providing some clear seperation between different parts of the system. Hurd is the only one of the three that does this, MkLinux and Darwin are both implemented as a single monolithic server on top of the Mach microkernel.

Also, they are based on different versions of Mach. I believe Darwin is based on 2.5, MkLinux on 3.0 and Hurd on 4.0 but don't quote me on that.

Re:My apologies to RMS

[Ektanoor]

Hurd is an OS with a much more "correct" architecture ideology than Linux and BSD. In its core it is much more universal and modular. Unfortunately, there is a huge gap between the paper and reality. The way it has been developed showed many HURDles among the GNU community. The more lavish, intellectual and less pragmatic approach to development made HURD a pariah. That's why Linux came up and ran over it. Being a traditional monlithic kernel that nearly carried all the ills of a 20 year kernel ideology, the penguin won just by being more closed to Earth.

However I hope that one day HURD will be able to hit the stands. It has been a pitty to see such a good idea living such a sad life. Frankly, we have been quite poor in kernels for the last years...

Re:What about exokernels?

[Arker]

The main purported advantage to microkernels are stability and flexibility, along with all the other good stuff that comes from modularity of course. A microkernel can run different personalities which present what we generally think of as a kernel interface to the outside, as user processors. So for instance the same box, the same microkernel, could be running a Windows personality for one user, a Mac for another, *nix for a third, all with effective root priveliges if need be, but without actually being able to do any damage outside their virtual sandbox... from a developers standpoint it's an incredible potential, I really can't do it justice but you should read this.

The potential here has never been exploited, unfortunately. Every existing microkernel AFAIK has wound up ditching the microkernel design at some point down the road, aiming to produce a particular personality (whether win32, the near-BSD personality of Darwin, etc.) and integrating key features of that personality into kernel space for performance reasons, essentially nullifying the whole microkernel idea. The HURD is the exception, and yes it's been a long time making, and it's still not ready yet, but if it ever does hit primetime it will be a very interesting system.

As to the performance hits, you're right that they are there, however there is a long history of some very smart people working on that problem, and it's gotten a LOT better. I think the current performance winner among microkernels is L4 and you can run a Linux personality on it without seeing a noticeable performance loss over running real Linux on the same processor - that's some very nice optimisation. There has been talk of porting the HURD to run on L4 instead of GNU Mach at some point, I think actually some people working on the problem areas, but for the moment there is no need - HURD is still very much in the developers only phase, it's not for production systems yet so performance isn't critical.

Re:Darwin and MkLinux?

[Matthias Wiesmann]

Here's where I think he's wrong. What he's describing here is how it works in Darwin (and NT) yes, but only because they moved those systems back into kernel space. But the way it works on a proper microkernel system (like the HURD) doesn't just run these things in a separate address space but at a different privilege level, so instead of crashing the kernel you simply crash a daemon and have to restart it. This does mean drawing the lines a little differently than they have, of course.

The problem, as I understood (can't remember where I read this) it is that in practice restarting the deamon that handles the swap disk is very tricky. Assume demon A is responsible for the swap infrastructure. If A crashes, the kernel has to restart it - but it has to do this without paging in or out any page (swap is not available anymore). Demon A must probably be reloaded from the file-system - but by design a micro-kernel should not know about file-systems.

I don't know if the Hurd can manage this kind of recovery. What I'm sure about is that such an recovery mechanism would be complex - and implementing it hard work.

I'm not convinced that the effort needed to enforce this kind of fault tolerance would be reasonable - on one hand you could tolerate failures of the Unix personality, on the other this would add complexity to both the kernel (to be able to restart demons/servers) and to the servers (they would need to be able to restore their state at restart) - IMHO, for a single OS machine, it sounds overkill.

One case where I think such an architecture makes a lot of sense is if you implement many virtualised OSes on one single machine. For instance you would have n logical servers that share one micro-kernel - in this case, if one of the virtual servers fails, the others are not affected.