Error in wake-for-shutdown

[narag]

I'm testing the simplest web app with the following code, taken almost verbatim from docs:

(ql:quickload "hunchentoot")

(defvar *server* (make-instance 'hunchentoot:easy-acceptor :port 4242))

(hunchentoot:define-easy-handler (home-page :uri "/wiki/") (name)
      (setf (hunchentoot:content-type*) "text/plain")
      (format nil "Hey~@[ ~A~]!" name))

(hunchentoot:start *server*)

I entered the code, line by line, in the console of SBCL 2.3.2 for Windows. After the last form, I see the log messages of the requests. I then write:

(hunchentoot:stop *server*)

And I got this error:

[2023-10-05 10:04:29 [ERROR]] Wake-for-shutdown connect failed: Socket error in "connect": 10049 (La dirección solicitada no es válida en este contexto.)

But after a few seconds, it succeds, returning:

#<HUNCHENTOOT:EASY-ACCEPTOR (host *, port 4242)>

And the prompt comes back while the browser reports that it's unable to connect. If the access is using Apache as a reverse proxy, it's uglier: first the last page (cached?) is returned, then Apached complains of an incorrect response from the proxy, then reports service unavailable.

I was reluctant to report the issue because, even if I've programmed a couple of http servers, I'm very new to the language. But I'm told that old programs are regressing with the same error, "after upgrading sbcl from 2.2.5 to 2.3.8 and all quicklisp packages".

Docs say that wake-for-shutdown creates a bogus request to allow the main loop (where accept() is called) to return. But accept() can be called with a timeout so that bogus request would be unnecessary, as accept() will unblock after the timeout. Being inside an infinite loop it would be called again anyway, after checking there's no pending shutdown command.

[metayan]

Maybe you can try cloning this repository to the Quicklisp local-projects directory.
Quicklisp is using hunchentoot v1.3.0 from May 2020, and there is a fix to wake-acceptor-for-shutdown in 7686239 that is not yet in Quicklisp.

Just for the record, I couldn't reproduce this issue on Linux. Neither with v1.3.0 nor with current master.