[hunchentoot-devel] Hunchentoot treatment of unhandled conditions

[Daniel Weinreb]

Hans Hübner wrote:
> On Mon, Mar 1, 2010 at 23:30, Daniel Weinreb <dlw at 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 at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20100302/426c5be2/attachment.html>