hunchentoot icon indicating copy to clipboard operation
hunchentoot copied to clipboard

LispWorks specific: the process slot of an acceptor may be unbound

Open Yehouda opened this issue 5 years ago • 2 comments

In the LispWorks version of start-listening, the acceptor process slot is is set after comm::start-up-server returns, which happens after the server starts to work, so something may try to access this slot before the setting.

It seems that happens only in (method shutdown (taskmaster)) and (method stop (acceptor)), so causes errors only if the server is being shutdown very quickly. That probably doesn't affect real application, but happens occasionally when we (LispWorks Ltd) run tests that use hunchentoot.

The right way to fix is:

  1. have :initform to the slot, so it is always bound.
  2. In the end of start-listening, after setting the slot, check if the acceptor was already shutdown and if it was, terminate the server.
  3. (method stop (acceptor)) need to check if the process is not NIL.

Other bits: The terminating of the server should be done now (since LW 6.1) by comm:server-terminate.
The function of the server, when it sees that the acceptor shutdown, can terminate it itself. It should also close the handle in this case,

Yehouda avatar Feb 10 '20 14:02 Yehouda

The right way to fix is:

Can you assemble it into a pull request?

stassats avatar Feb 10 '20 15:02 stassats

I didn't know what a pull request is until 10 minutes ago. I don't actually work with a branch of the source code, I downloaded it from quicklisp.

Yehouda avatar Feb 10 '20 15:02 Yehouda