portable way of sending notifying a process

[News123]

Hi,


I'm looking for a portable way (windows XP / Windows Vista and Linux )
to send a signal from any python script to another one
(one signa would be enough)

I have several python scripts started from different parent processes

occasionally some of the scripts want to tell another to reread it's
config file ( kill -HUP)

It seems, that neither the signals HUP / USR1 are implemented under windows.

What would be a light weight portable way, that one process can tell
another to do something?

The main requirement would be to have no CPU impact while waiting (thus
no polling)

Thanks for any suggestion of small portable libraries or code snippets.


The options, that I found so far seem to be a little too big or not
portable:
- sending the HUP signal doesn't work under win
- inotify doesn't work under win
- pyro seems to be a little too big for such a 'trivial' task
- watchdog might be a solution, but requires
three other non standard libraries to be installed.
So I'm not sure it's really lightweight


If nothing exists I might just write a wrapper around
pyinotify and (Tim Goldens code snippet allowing to watch a directory
for file changes)
http://timgolden.me.uk/python/win32_how_do_i/watch_directory_for_changes.html

and use a marker file in a marker directory
but I wanted to be sure of not reinventing the wheel.

 

[Dennis Lee Bieber]

What would be a light weight portable way, that one process can tell
another to do something?

The main requirement would be to have no CPU impact while waiting (thus
no polling)

I suspect there is no real portable way... Windows, for the most
part, relies upon everything coming in via a "message" to an open
window, or via an "event" object which is specified in one of:

win32event.WaitForSingleObject()
win32event.WaitForMultipleObjects() {which returns if any object in the
list is set}
win32event.MsgWaitForMultipleObjects() {which also returns if a Window
message has been received}

Note that "object" here is pretty much anything with a "handle"
(Event, Semaphore, Mutex, WaitableTimer, possibly process handles from
OpenProcess and from CreateFile)

If the other process has a "standard" Windows Console attached,
there is

GenerateConsoleCtrlEvent()

but the only choices seem to be control-c and control-break (the help
for win32api.GenerateConsoleCtrlEvent() just says an integer specifying
the signal, win32console.GenerateConsoleCtrlEvent() gives names for the
two specified)

All the above are accessed using functions in the win32 add-on
(don't recall the current name, since I've always used the ActiveState
Windows install it's included -- pywin32?)

You'd probably have to isolate the sending side to a module with
conditional imports/code... Though if you end up with the win32event
stuff, the receiving side is also going to need to be compatible.

 

[Chris Torek]

I'm looking for a portable way (windows XP / Windows Vista and Linux )
to send a signal from any python script to another one
(one signa would be enough)

This turns out to be pretty hard to do reliably-and-securely
even *without* crossing the Windows / Linux barrier.

It seems, that neither the signals HUP / USR1 are implemented under windows.

Signals are also very messy and easy to get wrong on Unix, with
earlier Python versions missing a few key items to make them
entirely reliable (such as the sigblock/sigsetmask/sigpause suite,
and/or setting interrupt-vs-resume behavior on system calls).

What would be a light weight portable way, that one process can tell
another to do something?

The main requirement would be to have no CPU impact while waiting (thus
no polling)

Your best bet here is probably to use sockets. Both systems have
ways to create service sockets and to connect to a socket as a
client. Of course, making these secure can be difficult: you must
decide what sort of attack(s) could occur and how much effort to
put into defending against them.

(For instance, even if there is only a "wake up, I have done
something you should look at" signal that you can transmit by
connecting to a server and then closing the connection, what happens
if someone inside or outside your local network decides to repeatedly
poke that port in the hopes of causing a Denial of Service by making
the server use lots of CPU time?)

If nothing exists I might just write a wrapper around
pyinotify and (Tim Goldens code snippet allowing to watch a directory
for file changes)
http://timgolden.me.uk/python/win32_how_do_i/watch_directory_for_changes.html

and use a marker file in a marker directory
but I wanted to be sure of not reinventing the wheel.

It really sounds like you are writing client/server code in which
the client writes a file into a queue directory. In this case,
that may be the way to go -- or you could structure it as an actual
client and server, i.e., the client connects to the server and
writes the request directly (but then you have to decide about
security considerations, which the OS's local file system may
provide more directly).

 

[Chris Angelico]

Your best bet here is probably to use sockets.  Both systems have
ways to create service sockets and to connect to a socket as a
client.

Further to this: If your two processes are going to start up, then run
concurrently for some time, and during that time alert each other (or
one alerts the other) frequently, a socket is an excellent choice. Use
a TCP socket on Windows, and either a TCP socket or a Unix socket on
Linux (I'd just use TCP on both for simplicity, but Unix sockets are
faster), and simply write a byte to it whenever you want to alert the
other side. You can largely guarantee that no other process can
accidentally or maliciously wake you, as long as you have some kind of
one-off handshake on connection - even something really simple like
sending a random nonce, having the other end send hash(nonce +
password), and compare.

Chris Angelico
Huge fan of TCP sockets (hello MUDs!)

 

[News123]

Thanks for all your feedback.


Well, I'll play a little and go either for a wrapper around
ways to detecth a file change or for a tiny socket solution.

Thanks again.