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 Tue, 06 Jul 1999 11:24:56 GMT

In article <> you wrote:

> as far as i've understood, pth use user-land threads... So I guess that to the
> contrary of Linuxthreads, pth threads aren't include into the kernel process
> table... 

Yes, correct. Pth is pure user-land threading library.

> An approach which is very interesting for those who (like me) encounter
> a problem with process proliferation (ok, i'm gonna use load-balancing so i'll
> not be bothered anymore; still, this issue continues to draw my interest)
> anyway, i was wondering if pth couldn't be used as a general library: i mean a
> program could be linked to pth which would provide either the native support if
> it exists or the pth system. It may even be possible for a program to get both:
> the user-land threads of pth AND the native threads (through pth)
> what du think of it ?? is it a silly idea or a sane question ? ;-)

You already get this indirectly. Pth provides a pthread wrapper API for the
fallback situation where no vendor pthread library exists. So when you want to
use the native threads, you link against the vendor stuff. When you want the
emulated pthreads, you link against pth.

The other more hidden approach you mention is a little bit hard to achieve:
You cannot call the vendor pthread functions from within the pthread API of
pth because you get recursive calls to yourself. So the only possibility would
be to call the vendor pthread stuff from the regular pth API. But here the
problem is that pth provides features (like explicit event handling, message
ports, etc.) which you cannot easily map onto vendor pthread stuff.

So although your suggestion is a good one, IMHO it shouldn't be solved
directly inside Pth. Instead look at Gtk's glib: They have a minimal
abstraction layer over various threading libraries. Here you always just use
one API, but in the background is drives different implementations.  A vendor
pthread lib and Pth can be those implementations. A similar thing is done by
APR: ap_create_thread() dispatches between the various threading
implementations. Ok, currently statically, but one could also do it
dynamically, i.e. link APR against a vendor pthread and Pth and let the
application switch or at least select between them under runtime.

                                       Ralf S. Engelschall

View raw message