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

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

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

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

> Enjoy. I got bit by all of these in the last 48 hours, while working on
> my proxy code.
> D

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