signals (again)

B

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_directory(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?
 
P

Paul Rubin

bill said:
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?

Use asynchronous calls and/or a separate thread.
 
B

bill

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?
 
M

Michael Hudson

bill said:
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_directory(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?

I don't think you can, sorry.

Cheers,
mwh
 
B

bill

I found a good solution to this problem in Richard Steven's
_Network_Programming_. 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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top