thread pool helpers

Stefan (metze) Metzmacher metze at
Tue Apr 28 13:54:29 GMT 2009

Hi Tridge,

> 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).

What is the exact difference between both sematics?

>  - 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.

Does that also happen when you explicit dlopen
I think in the cyrus sasl plugin case libpthread was loaded implicit
as the plugin itself was linked against it.

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

That would mean we need to use syscall wrapper for some functions,
or for all functions from glibc?

Would this syscall wrapper work with pthreads or only with clone()?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url :

More information about the samba-technical mailing list