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
