signals (again)

[bill]

I see this (or similar) question occasionally looking back through the
archive, but haven't yet seen a definitive answer, so I'm going to ask
it again.

Consider the following:

while True:
do_something_to _files_in_direc tory(fd)
fcntl(fd, F_NOTFIY, DN_CREATE)
signal.pause()


How do you deal with the signal that occurs after the fcntl and before
the pause? The solution to sleep instead of pause is aesthetically
ugly and doesn't really help. I've thought about examining the stack
trace in the signal handler for SIGIO and responding appropriately, but
that's pretty ugly too. I saw some mention of implementing a try:
construct that would delay receipt of the signal for one atomic python
instruction, and that seemed like a good idea, but I didn't see much
follow up on that. What's the pythonic thing to do here? How can I
guarantee timely response to the creation of a file in the directory
referenced by fd?

[Paul Rubin]

Re: signals (again)

"bill" <bill.pursell@g mail.com> writes:[color=blue]
> What's the pythonic thing to do here? How can I
> guarantee timely response to the creation of a file in the directory
> referenced by fd?[/color]

Use asynchronous calls and/or a separate thread.

[bill]

Re: signals (again)

How does that help? I interpret "use asynchronous calls" to mean "use
fcntl to set an FN_NOTIFY on the directory in order to be alerted when
something needs to be done." But the method of doing that which I
outlined above has a critical section in which the incoming signal will
not be noticed. All of the solutions I can think of for getting around
it involve a lot of acrobatics that I'm fairly certain aren't
necessary, and more to the point I don't think they actually solve the
problem. There is always a section in which the signal arrives just
before the pause, so it doesn't wake us up out of the pause as it is
intended to. We can set globals in the signal handler, and then check
them right before the pause, but if they get set after we check, then
we're hosed. I was hoping that perhaps the following code might be
atomic:

if notify_occurred or signal.pause():

but I'm almost certain that it's not.

The problem is localized, so I don't see how invoking a seperate thread
is useful. Could you elaborate on how you think that will help?

[Michael Hudson]

Re: signals (again)

"bill" <bill.pursell@g mail.com> writes:
[color=blue]
> I see this (or similar) question occasionally looking back through the
> archive, but haven't yet seen a definitive answer, so I'm going to ask
> it again.
>
> Consider the following:
>
> while True:
> do_something_to _files_in_direc tory(fd)
> fcntl(fd, F_NOTFIY, DN_CREATE)
> signal.pause()
>
>
> How do you deal with the signal that occurs after the fcntl and before
> the pause?[/color]

I don't think you can, sorry.

Cheers,
mwh

--
Get out your salt shakers folks, this one's going to take more
than one grain. -- Ator in an Ars Technica news item

[bill]

Re: signals (again)

I found a good solution to this problem in Richard Steven's
_Network_Progra mming_. It seems like everything shows up in Steven's
books! Rather than pausing, you do a blocking read on a pipe. You
only write to the pipe from within the signal handler. However, this
brings up the better question: why was 'pause' ever implemented? No
matter what you do, the signal that you expect to wake you up may occur
immediately prior to the pause, and you'll miss it. Starting that
question in a new thread.