Hans Hübner wrote:
On Mon, Mar 1, 2010 at 23:30, Daniel Weinreb dlw@itasoftware.com wrote:
Hunchentoot's accept-connections called usocket:socket-accept, which signaled a usocket:unknown-error. Nothing handled this condition. This happened in a server, which crashes (rather than going into the interactive debugger) when there is an unhandled condition.
[...]
Are there any plans regarding this, or advice about it?
I do not think that Hunchentoot should continue as if nothing happened when usocket:socket-accept signals an unknown condition.
Yes, I agree. I was thinking in terms of providing a way for the application using Hunchentoot to have a way of controlling what happens next in such a circumstance, such as logging, notifying some other process, etc.
After all, something bad could have happened to the socket, making the following select hang forever or the following accept just signal the same error again, both being undesireable (hanging vs. busy looping).
The real question is: What is the original error that was converted into an unsocket:unknown-error?
In this case, it was an errno 24, which is EMFILE, "too many open files". Yes, ideally usocket would have a generic condition for this. But from my point of view, the most important thing is to have some way to control what happens in the face of a condition that we cannot anticipate.
It would be something like the existing handle-message's handler-bind, but "closer to the base of the stack" so that it would handle conditions signaled within, e.g., accept-connection.
Thanks.
-- Dan
The condition has a real-error slot that can be examined to find out (and the print method prints it using "The condition ~A occured."). Once the original error is known, it can be decided how usocket must be fixed to map the platform specific error to a usocket condition class and if Hunchentoot can safely ignore this error when it occurs during an accept. Please let us know what you find out.
-Hans
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel