thread pool helpers
Stefan (metze) Metzmacher
metze at samba.org
Tue Apr 28 13:54:29 GMT 2009
> 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 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.
Does that also happen when you explicit dlopen libpthread.so?
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...
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://lists.samba.org/archive/samba-technical/attachments/20090428/04e0e2bc/signature.bin
More information about the samba-technical