Forking SocketServer daemon -- updating state

[Irmen de Jong]

Reid Priedhorsky wrote:

> Another possibility is that the signal handler simply sets a needs_update
> flag, which I could check for in a handle_request() loop. The disadvantage
> here is that the update wouldn't happen until after the next request is
> handled, and I would like the state to be available for that next request.
> A solution might be to send a signal followed by a dummy request, which
> seems a bit awkward.
> 
> Any other ideas or suggestions?

Just send a special type of request that signifies that an update is 
wanted, and act on that?

Basically you need to find a way to let two processes talk to each 
other. There are a lot of possibilities here (IPC). The simplest
would be to reuse the one you already have (the request handler!).
Another solution might be to use Pyro.
Or just open a custom socket yourself to send messages.
Or stick with your idea of using a signal handler. But I don't know
if you can let a signal handler run for a long time (as you already
asked yourself), and it won't be portable to Windows for instance.

You could maybe use threads instead, and then use some form of
thread synchronization primitives such as threading.Event
(threads would remove the need to do IPC).

Hope this helps a bit,

--Irmen