On Sun, 01 Oct 2006 17:57:34 -0400, Travis Cross travis@travislists.com wrote:
My understanding is that because of issues with shared memory between threads, killing a thread should always be considered a bit drastic, as there is no real guarantee that it won't corrupt the entire lisp image. [1]
Ouch!
When I write listeners such as this, to provide for a normal shutdown I close over a function that flips a flag variable telling the listener to stop, then initiates a socket connection to the listener to break the socket-accept block. [2]
It seems that something like this [3] might be the correct solution here as well. For a normal shutdown, one tends to prefer to let current workers finish their tasks up anyway. Providing for both the 'clean' shutdown and the 'nuke them all and take your chances' approach would probably be the most flexible interface.
Yeah, I'll probably implement something like this in the future. At the moment I'm just mimicking the LispWorks API where killing the server process is the documented way to stop the server.
http://www.lispworks.com/documentation/lw50/LWRM/html/lwref-56.htm