thread pool helpers

[Jeremy Allison]

On Tue, Apr 28, 2009 at 05:47:13PM +1000, tridge at samba.org wrote:
> Hi Volker,
> 
> I think you've created a really nice API, but the brokenness of
> pthreads make me think that we're better off implementing that API
> either on top of fork() or on top of a raw clone() call.
> 
> The particular brokenness in pthreads that I'm thinking of is:
> 
>   - when you have any pthreads active on current Linux/glibc, then
>     some calls that Samba relies heavily on become extremely slow. For
>     example the setreuid() call takes 150x longer (and is racy) when
>     you have any threads active (this is because of a mismatch in
>     setreuid semantics between POSIX and the linux kernel, which glibc
>     tries to compensate for rather badly).
> 
>  - if you use the approach of dlopen() of libpthread.so to avoid
>    always linking to pthreads then this breaks gdb (at least on
>    Ubuntu, and I think on many other platforms). What happens is that
>    gdb needs to know about the fact that the program is threaded, and
>    once it loaded libpthread then gdb gives a threading error and
>    refuses to continue.
> 
> The only way I know of to work around these sorts of problems involves
> us making our own syscall wrappers using syscall(). Do we want to take
> that approach or do you think your api would work well enough on top
> of fork() ?

Is there a way we can wrap this, so that on systems with non-broken
pthread semantics can work with pthreads, and on Linux we use something
else ?

I really don't want to go down the route of making Samba very
Linux specific, and like it or not pthreads is the threading
standard on UNIX.

How do other programs on Linux using pthreads cope with these
issues ? There are *many* threaded programs on Linux that
don't have problems. Google runs lots of them :-).

The setreuid() call being racy is an issue for us, but it might
be better to log a glibc bug and try and get this fixed rather
than avoid pthreads. Are there any other calls that break, or
is it just setreuid() ?

The dlopen() problem goes away once we link pthreads directly.

Jeremy.