thread pool helpers

tridge at tridge at
Tue Apr 28 07:47:13 GMT 2009

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

Cheers, Tridge

More information about the samba-technical mailing list