signals (again)

Discussion in 'Python' started by bill, Aug 10, 2005.

  1. bill

    bill Guest

    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?
     
    bill, Aug 10, 2005
    #1
    1. Advertising

  2. bill

    Paul Rubin Guest

    "bill" <> writes:
    > 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.
     
    Paul Rubin, Aug 11, 2005
    #2
    1. Advertising

  3. bill

    bill Guest

    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?
     
    bill, Aug 11, 2005
    #3
  4. "bill" <> writes:

    > 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

    --
    Get out your salt shakers folks, this one's going to take more
    than one grain. -- Ator in an Ars Technica news item
     
    Michael Hudson, Aug 11, 2005
    #4
  5. bill

    bill Guest

    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.
     
    bill, Aug 12, 2005
    #5
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. amit
    Replies:
    0
    Views:
    394
  2. che
    Replies:
    2
    Views:
    502
  3. abcd

    Importing again and again

    abcd, Jun 8, 2006, in forum: Python
    Replies:
    9
    Views:
    330
    Maric Michaud
    Jun 9, 2006
  4. Mitko Haralanov

    Signals and threads again

    Mitko Haralanov, Oct 13, 2006, in forum: Python
    Replies:
    0
    Views:
    264
    Mitko Haralanov
    Oct 13, 2006
  5. Replies:
    4
    Views:
    407
Loading...

Share This Page