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

No linux? No async-io? No threads? You can skip this.

My, my, my. The fascinating things you learn about GlibC 2.0.x (6 or 7
in this case) and linuxthreads. Here's a couple good and interesting
ones I found while working on proxy code. I figured that they may be
similarly applicable to other people hacking squid code with threads:

1) FILE objects are bad. If you used them during your threaded app,
there's a small chance that a thread may fail to acquire a spinlock and
never be able to terminate. If that happens, other threads will suffer
the same fate. Bad. The app then sucks CPU time busy/waiting.

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)

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.

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)

Enjoy. I got bit by all of these in the last 48 hours, while working on
my proxy code.
D
Received on Tue Apr 13 1999 - 06:51:28 MDT