thread pool helpers
tridge at samba.org
tridge at samba.org
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 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() ?
Cheers, Tridge
More information about the samba-technical
mailing list