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