stoye at stoye.com
Mon Mar 10 06:32:47 PDT 2008
i think my post from 29. Oktober 2007 ("*multiprocessing-socket-io*
and implications") either has been overlooked,
or didn't made sense for anyone, i'll repeat it here, maybe someone
can comment on it.
Setting ccl::*multiprocessing-socket-io* to nil provides some benefits
(see mail from Gary Byers from 13. Mai 2005 14:29:32 MESZ),
but it is problematic in connection with threads which are blocked
If you kill a process blocked by ccl:accept-connection the socket
stays open (read: is not closed even when closed in an unwind-protect
until the next connection arrives and even after that, we have
an orphaned connection in state "CLOSE_WAIT" (seen with netstat). I
noticed the problem by using some http-server packages: Since they
kill their listening processes, none of them is able to stop and
restart the service when ccl::*multiprocessing-socket-io* is nil,
since the port is "already in use" (caused by the unclosed socket).
I got around this by modifying the "wait" clause in ccl::socket-accept
to resemble the behavior of the T clause
(change socket options to include #$O_NONBLOCK before calling with-
But i am shure this isn't the right way.
Here is a typical "usecase" from hunchentoot, running a
(listening-)process with the following code:
(setf socket (ccl:make-socket ...))
(loop (funcall function (ccl:accept-connection socket :wait
(cl:ignore-errors (close socket))))
I have little to no experience writing socket-code on a lower level
and i think that i have two conflicting demands:
a) let the thread block on this socket operation (on a system layer)
b) be able to kill this process and close the socket
so maybe i can state a more concrete question:
Is there any way to close a socket, when its thread is blocked during
ccl:accept-connection (really in socket-accept),
assuming ccl::*multiprocessing-socket-io* is nil.
Or is it possible to change the socketoptions when a connection
arrives (make it blocking?)
Sure there is a very easy solution: let *multiprocessing-socket-io* be
but i think this isn't "The Right Thing" either.
More information about the Openmcl-devel