httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralf S. Engelschall" <>
Subject Re: GNU Portable Threads (pth)
Date Mon, 05 Jul 1999 13:53:47 GMT

In article <> you wrote:
> On Sun, Jul 04, 1999 at 07:27:01PM +0200, Ralf S. Engelschall wrote:

>> For instance it includes a flexible event facility inspired by Paul Vixies
>> eventlib which allows threads to explicitly wait until various types of events
>> occur, including pending I/O on filedescriptors, asynchronous signals, elapsed
>> timers, pending I/O on message ports, thread and process termination, and even
>> customized callback functions.  Or it provides inter-thread communication
>> through message ports as known from the good old AmigaOS' Exec.
> I would like to see the pth could be run on multiprocessor machines.
> I think there are many multiprocessor machines used for WWW,
> and using pth for apache could cut down the benefits of multithreading.

A portable user-land threading library can not provide support for
multiprocessor machines. At least not unless you break the portability goal,
because in POSIX and ANSI C there is no support for handling multiprocessor

I think you misunderstood the intentions of pth a little bit: it's not
performance, it's maximum portability while still providing a multithreading
environment. So when you think about Apache and pth you should more think
about pth as a _fallback_ threading library for Apache in case no vendor
pthread library exists. And not for a general solution to squeeze out maximum
performance of Apache. 

I tried to optimize pth at some important edges (for instance the event
manager in the scheduler), but whenever I had to decide between portability
and performance I always gave portability the preference. Because portability
is why I wrote such a library. Else it would be just the 1001th thread library
and this would be useless because there exists already lots of others (I've
currently already 14(!) other libs in my evaluation area on disk).

                                       Ralf S. Engelschall

View raw message