I'm actively experimenting with clone() threads on one of my personal
projects. The idea is to code a 3rd generation web server with
dedicated threads accepting/processing requests, sending the requested
objects to the requestor, and executing dynamicly loaded CGI "modules"
which live in the server's space. Thanks to Randy Chapman for helping
me organize my thoughts on it.
The biggest obsticle to doing things with clone() threads is the
complete lack of support. Neither X, libc, db, or anything else is
threadsafe out of the box. You and sct both mentioned ways that
threads can currently upset the kernel -- but so far nothing that a
little locking and common sense can't handle. And there are no
existing locking/syncronization functions -- though alan cox was nice
enough to assult me with a clue stick, and I'm trying to learn GAS's
asm syntax well enough to make an cmpxchg inline so I can make a
decent semaphore. I'm also looking at the mmalloc package that comes
with gdb. GNU mmalloc is certainly not the best malloc around, but it
promises multiple heaps which I hope might be a sort of simple garbage
collection, and I'm curious if having multiple heaps leads to
finer-grain locking for malloc() functions and any sort of win.
The only real "problem" that I've noticed, and maybe its not even a
problem, is that when a thread's parent dies, the thread will continue
happily until it finds its own reason to die. I sorta expected a
dying process to take all its child threads with it.
Christopher