[Openmcl-devel] Unexpeted behaviour when running Hunchentoot example on windows

[Bill St. Clair]

On 2/15/10 4:55AM, Hans Hübner wrote:
> Allan,
> 
> are you using the latest version of Hunchentoot?  I have just checked
> that we are normally ignoring usocket:timeout-error in
> hunchentoot:read-initial-request-line, so the error should not
> propagate to the debugger (unless hunchentoot:*catch-errors-p* is
> nil).

Apparently, Hans, that's exactly why Allan is seeing what he's seeing:

On 2/14/10 3:07PM, Allan Dee wrote:

> I do this:
>
> Welcome to Clozure Common Lisp Version 1.4-r13122  (WindowsX8664)!
> ? (asdf:oos 'asdf:load-op :hunchentoot)
> #<LOAD-OP NIL #x14137D93D>
> ? (setq hunchentoot:*catch-errors-p* nil)
> ? NIL
> ? (hunchentoot:start (make-instance 'hunchentoot:acceptor :port 4242))
> ? #<ACCEPTOR (host *, port 4242)>
> ?

> This could be considered a bug, though:  Even when debugging, one does
> not want to end up in the debugger when a usock:timeout-error or
> end-of-file is signalled in hunchentoot:read-initial-request-line.
> Both are normal conditions that occur when the browser decides to
> close a persistent connection or does not send a new request within
> the timeout configured on the server.

I agree that it could be considered a bug. I think that Hunchentoot
should catch expected "errors", even when hunchentoot:*catch-errors-p*
is true.

-Bill