portable way of sending notifying a process

Chris Torek nospam at torek.net
Sun May 29 21:44:17 EDT 2011


In article <4de183e7$0$26108$426a74cc at news.free.fr>
News123  <news1234 at free.fr> wrote:
>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).
-- 
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W)  +1 801 277 2603
email: gmail (figure it out)      http://web.torek.net/torek/index.html



More information about the Python-list mailing list