thread pool helpers

tridge at tridge at
Sat May 2 11:28:52 GMT 2009

Hi Metze,

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

The kernel setreuid call changes just the one thread, glibc doesn't
want that, so it uses signals between the threads on each call to

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

I don't know - that's worth testing!

Cheers, Tridge

More information about the samba-technical mailing list