We are running into some of the limitations of cmucl's threading implementation. It's annoying, but mostly because I should have looked this up when we first started using cmucl instead of just checking that multiprocessing was mentioned somewhere in the EncyCMUCLopedia.
It turns out that cmucl has user-level, cooperative threading. Which means that when, for example, I create a Lisp thread and inside it call a function to make a socket connection to some remote host that isn't online, Lisp is completely dead to the world until the connect system call decides to return.
No other Lisp threads will run until that happens. No http requests will be served, no nothing. The listener is dead. (Sometimes so dead that SIGINT isn't enough to wake it up.)
I'm not sure what the best solution to this problem is.
Like I said, annoying.Posted by jjwiseman at January 23, 2002 05:21 PM
...or convince the OS to let the connect call fail sooner. I wonder how dangerous this would be:
echo 0 > /proc/sys/net/ipv4/tcp_syn_retries
A tcp_syn_retries value of 0 results in the attempt failing after about three seconds, a value of 1 fails in about eight.
I can't see any way to set this on a per-socket basis.
How many 8-second long delays in a row before someone either thinks the web server isn't going to return a page or the computer at the other end of the phone line is broken?Posted by: jjwiseman on January 24, 2002 02:23 PM
Heh. Today someone posted a message to a cmucl mailing list about their experiences with SIGALRM preemption enabled:
> eventually, CMUCL dies a horrible memory corruption death.Posted by: jjwiseman on February 1, 2002 01:50 AM