Hi Peter,
2009/7/6 Peter Stiernström peter.stiernstrom@blixtvik.se
I had a quick peek at client-as-string and it does indeed not handle the sb-bsd-sockets:not-connected-error and if I put a handler-case around body of client-as-string returning nil when the exception appears I can not reproduce my problem anymore.
This wouldn't provide a portable solution though :-P
This really is a bug that requires fixing in usocket. There are multiple issues:
- As shown in the backtrace, the problem is that the getpeername() call fails for a socket that is not connected anymore. SBCL does the right thing by signalling a condition. Other implementations (I checked CCL) seem to behave differently, i.e. return NIL in such a case.
- Usocket does not unify the behavior, so the implementation specific condition percolates to the caller, Hunchentoot in this case.
- Hunchentoot is not prepared to handle conditions when creating a new worker thread. The call to CLIENT-AS-STRING is made when creating the name for the handler process of a new incoming connection, and that is done in the context of the server thread. Therefore, the signalled condition will stop the acceptor process.
I spent some thoughts on how a "portable solution" would look like, but given that the Lisp implementations vary greatly in behavior, fixing usocket would be a pretty large task that I don't have the time to do right now. Thus, I would propose this patch:
http://bknr.net/trac/changeset/4428?format=diff&new=4428
It handles all conditions that are signaled during worker process creation, under the theory that we want to prevent the acceptor process from crashing under all circumstances. This is not a clean solution in that it may paper over bugs, but given the limited number of function invocations that are surrounded by a HANDLER-CASE, I'd say that this is a proper intermediate fix.
Please give it a try and let me know if it solves the problem for you.
-Hans