[Zope-Coders] Signal forwarding

[Chris McDonough]

On Wed, 2002-10-09 at 13:07, Guido van Rossum wrote:
> > This might be a use case for ditching complicated signal handlers
> > entirely and moving to some sort of simple socket server for
> > administrative functions.  We could still have signal handlers on a
> > process if we wanted, but the signal handlers could just write something
> > to the socket.
> 
> Yes, please!  Jeremy & I found at least one case where an attempt to
> close a storage from a signal handler could conceivably try to acquire
> a lock (when aborting a current transaction).

So the problem would be that if some other piece of code already held
the lock, it could result in deadlock?

> > One problem is controlling security.  On UNIX, we'd want to use a UNIX
> > domain socket protected in such a way that only certain folks could send
> > commands to it.  On Windows, we'd probably just punt and open up a TCP
> > socket that could only be connected to via localhost.
> 
> Right.  That's pretty simple.

This might also solve another related problem inasmuch as we often want
to call into Zope in such a way that we exercise a bit of code in
exactly the same way it's exercise when a request comes in via a web
request.  When a web request happens, ZPulisher wraps the published
object in a context that contains a REQUEST object with real
authentication credentials and a SERVER_NAME and a URL and some other
stuff.  App code in Zope often relies on this information.  Using a
socket we could do this without needing to store any credentials in a
calling script (a security risk).

The hard part is constructing the language to communicate with Zope and
dealing with responses.  I suppose the stuff that a client sends could
just be HTTP verbs.  I'm less sure about responses.

Any volunteers? ;-)

- C