<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<br>
Hans Hübner wrote:
<blockquote
cite="mid:fd2982321003012250n77daaefcse4855cc1255e6613@mail.gmail.com"
type="cite">
<pre wrap="">On Mon, Mar 1, 2010 at 23:30, Daniel Weinreb <a class="moz-txt-link-rfc2396E" href="mailto:dlw@itasoftware.com"><dlw@itasoftware.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
[...]
</pre>
<blockquote type="cite">
<pre wrap="">Are there any plans regarding this, or advice about it?
</pre>
</blockquote>
<pre wrap=""><!---->
I do not think that Hunchentoot should continue as if nothing happened
when usocket:socket-accept signals an unknown condition.</pre>
</blockquote>
Yes, I agree. I was thinking in terms of providing a way for<br>
the application using Hunchentoot to have a way of<br>
controlling what happens next in such a circumstance,<br>
such as logging, notifying some other process, etc.<br>
<blockquote
cite="mid:fd2982321003012250n77daaefcse4855cc1255e6613@mail.gmail.com"
type="cite">
<pre wrap=""> 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? </pre>
</blockquote>
In this case, it was an errno 24, which is EMFILE, "too many<br>
open files". Yes, ideally usocket would have a generic condition<br>
for this. But from my point of view, the most important thing<br>
is to have some way to control what happens in the face of a<br>
condition that we cannot anticipate.<br>
<br>
It would be something like the existing handle-message's<br>
handler-bind, but "closer to the base of the stack" so that<br>
it would handle conditions signaled within, e.g., accept-connection.<br>
<br>
Thanks.<br>
<br>
-- Dan<br>
<blockquote
cite="mid:fd2982321003012250n77daaefcse4855cc1255e6613@mail.gmail.com"
type="cite">
<pre wrap="">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
<a class="moz-txt-link-abbreviated" href="mailto:tbnl-devel@common-lisp.net">tbnl-devel@common-lisp.net</a>
<a class="moz-txt-link-freetext" href="http://common-lisp.net/mailman/listinfo/tbnl-devel">http://common-lisp.net/mailman/listinfo/tbnl-devel</a>
</pre>
</blockquote>
</body>
</html>