Experimental patch to avoid thread explosion

[Sergio Lopez]

Hello,

One of the most usual errors found by Hurd's developers is the "zalloc's
panic" one. I think that this panic could be (usually) related with the
extremly high number of threads that some translators (i.e. ext2fs)
spawn when there's a significant amount number of activity over it
(already discussed here
http://lists.gnu.org/archive/html/bug-hurd/2002-04/msg00003.html and
http://lists.gnu.org/archive/html/bug-hurd/2002-06/msg00263.html).
Antrik have also done a research about this issue
( http://hurd.gnufans.org/bin/view/Hurd/ZallocPanics ).

This is an experimental (just for testing) patch that (I hope) helps
with debuging this issue, and also seems to make the system a little
more robust. 

It is extremly simple. Everytime a thread is going to serve a request,
it checks if nreqthreads == 0, and spawns a new thread if true. But
before spawning the new thread, it increments nreqthreads by 1 (to count
the new thread), so until this new thread receives a request
(nreqthreads is decremented at internal_demuxer), more threads can't be
created. What we do is, if a certain number of threads are already
spawned (THREAD_DELAY), we put the new thread to sleep for a time
(DELAY), so we're implicity delaying threads creation, giving time to
other threads to finish their requests.

On some machines (fast processor, slow I/O, or both), this isn't enough
to avoid a slowly but constant thread incrementation due to Mach's
pageouts, so a fixed limit is needed (THREAD_MAX) for self-paged
translators.

It's recommended to play with this values (THREAD_DELAY, THREAD_MAX,
DELAY) and enable debug (LP_DEBUG) to see how new threads are created.

Happy hacking!

manage-multithread.diff
Description: Text Data