Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #6496 > unrolled thread

portable way of sending notifying a process

Back to article view | Back to comp.lang.python

Contents

  portable way of sending notifying a  process News123 <news1234@free.fr> - 2011-05-29 01:23 +0200
    Re: portable way of sending notifying a  process Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2011-05-29 00:09 -0700
    Re: portable way of sending notifying a  process Chris Torek <nospam@torek.net> - 2011-05-30 01:44 +0000
      Re: portable way of sending notifying a process Chris Angelico <rosuav@gmail.com> - 2011-05-30 12:03 +1000
        Re: portable way of sending notifying a process News123 <news1234@free.fr> - 2011-05-30 11:18 +0200

#6496 — portable way of sending notifying a process

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.

[toc] | [next] | [standalone]

#6516

On Sun, 29 May 2011 01:23:18 +0200, News123 <news1234@free.fr> declaimed
the following in gmane.comp.python.general:
> 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.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#6607

In article <4de183e7$0$26108$426a74cc@news.free.fr>
News123  <news1234@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

[toc] | [prev] | [next] | [standalone]

#6609 — Re: portable way of sending notifying a process

On Mon, May 30, 2011 at 11:44 AM, Chris Torek <nospam@torek.net> wrote:
>>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.

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!)

[toc] | [prev] | [next] | [standalone]

#6643 — Re: portable way of sending notifying a process

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.


On 05/30/2011 04:03 AM, Chris Angelico wrote:
> On Mon, May 30, 2011 at 11:44 AM, Chris Torek <nospam@torek.net> wrote:
>>> 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.
> 
> 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!)

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web