thread pool helpers

[tridge at samba.org]

Hi Jeremy,

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

Do you know of any that do euid/egid changing and also use threads?

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

The problem is that its really POSIX that is broken. The kernel does
the right thing in my opinion - it allows threads to have different
euid/euid. For a file server, this is great.

POSIX doesn't allow that, so we either have to convince the glibc
maintainers to not follow POSIX, or we have to get POSIX changed.

 > Are there any other calls that break, or is it just setreuid() ?

I haven't checked to see what happens with the supplementary group
calls. I wouldn't be surprised if they do the same.

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

yes, but that also means that many other operations slow down on many
platforms. On some systems (eg. aix) malloc() suddenly becomes much
slower when you link to libpthread. That is fixed now on Linux (or at
least mostly fixed), but its still a problem on other OSes.

Most threaded programs don't care about this sort of lossage, but in
Samba I think we'll be upset if we start losing significant chunks of
performance because we start linking to pthreads.

Cheers, Tridge