Re: [Marginally OT]: Things you didn't know about threads

Henrik Nordstrom wrote:
>
> > 2) Alas, snprintf and friends aren't safe. I had problems with them, and
> > peeked in the GLIBC source. Would you believe that it uses a FILE object
> > to print to a string? *sigh* Time to write replacement code (which is
> > what I've been doing. I should be at home)
>
> There is one fully functional replacement delivered with squid:
> squid/lib/snprintf.c. Gets used if any of the sprintf family of
> functions is missing. "env ac_cv_func_snprintf=no ./configure ...."
>
> > 3) linuxthreads uses SIGUSR1 to send management signals between threads.
> > If it gets too busy, it can interrupt it's own raise()/kill() call, and
> > then suddenly stops dead waiting for signals that will never arrive.
>
> Are you sure? kill() is supposed to be uniterruptible.

I've managed to see this in action with strace. It looks like it happens
at the call gate. At least this is what _appears_ to be going on.

>
> > 4) For all those of you who increased the number of file-descriptors and
> > use async-io. I spent a day trying to figure out why my nice little app
> > blew up. Answer: fd_set! (or, more properly the _size_ of fd_sets).
> > glibc doesn't use the kernel's values, and your stack gets overwritten
> > if the kernel's value is larger. Rebuild the glibc and pthread libraries
> > (after hacking in larger numbers). (Why is it so? The management thread
> > is a heavy select() user, and something about the way per-thread-stacks
> > are allocated really seems to exacerbate the overrun)
>
> Hmm.. the kernel should not overrun fd_sets unless called wrongly
> (higher n than the allocated fd_set size), and the management thread
> starts very early so it should not use any high filedescriptors.

I've got some stuff that blows up fairly reliably. I've found that if I
use getrlimit()/setrlimit() to lower the maximum number of descriptors
before starting any threads (drop it to 200, say), then there's no
problems.

I attribute the problems to glibc overriding the kernel header values
for fd set sizes, open max and such in the headers.

> Other functions in the library which depends on fd_set seems to be the
> resolver and SUN RPC.

Haven't had any problems with these, but I don't use either in my
threaded apps.

D
Received on Tue Jul 29 2003 - 13:15:57 MDT