what can be used in a signal handler

Discussion in 'Python' started by hg, Jan 18, 2007.

  1. hg

    hg Guest

    Hi,

    I posted an equivalent question earlier ... but am still not sure:

    I currently (under Linux) have a program that uses Queue.put (raw_input(''))
    in a signal handler and Queue.get() in the main/only thread.

    It works but I want to know if it is legal / what type of synchro API I have
    the right to use in a signal handler.

    Regards,

    hg
    hg, Jan 18, 2007
    #1
    1. Advertising

  2. In article <3zKrh.30692$>,
    hg <> writes:
    |>
    |> I posted an equivalent question earlier ... but am still not sure:
    |>
    |> I currently (under Linux) have a program that uses Queue.put (raw_input(''))
    |> in a signal handler and Queue.get() in the main/only thread.
    |>
    |> It works but I want to know if it is legal / what type of synchro API I have
    |> the right to use in a signal handler.

    Strictly, no and none.

    C and POSIX's specifications of signal handling is a complete mess.
    ALL handling of ALL real signals is undefined behaviour, though few
    programmers realise that and POSIX depends on it. As that would make
    all Unices (and Microsoft systems) unusable, you can reasonably assume
    that there is some signal handling that will work.

    But what? Which is where you came in.

    The situation is that most things that seem to work do actually work,
    in some environments and under some circumstances. You can never be
    sure when they will stop working, however, and all bets are off when
    you port signal handling code to a new system. And, really but REALLY,
    do not mix it with very high levels of optimisation or rely on it
    being in any way thread safe.

    I can't tell you whether the code of Queue is intended to work if an
    active Queue.get is interrupted by a signal which then does a Queue.put,
    but that is the sort of circumstance where things get very hairy. Even
    if Python has code to enable that case, it won't be 100% reliable on all
    systems.

    Sorry. But that is the situation :-(


    Regards,
    Nick Maclaren.
    Nick Maclaren, Jan 18, 2007
    #2
    1. Advertising

  3. hg

    hg Guest

    Nick Maclaren wrote:

    >
    > In article <3zKrh.30692$>,
    > hg <> writes:
    > |>
    > |> I posted an equivalent question earlier ... but am still not sure:
    > |>
    > |> I currently (under Linux) have a program that uses Queue.put
    > |> (raw_input('')) in a signal handler and Queue.get() in the main/only
    > |> thread.
    > |>
    > |> It works but I want to know if it is legal / what type of synchro API I
    > |> have the right to use in a signal handler.
    >
    > Strictly, no and none.
    >
    > C and POSIX's specifications of signal handling is a complete mess.
    > ALL handling of ALL real signals is undefined behaviour, though few
    > programmers realise that and POSIX depends on it. As that would make
    > all Unices (and Microsoft systems) unusable, you can reasonably assume
    > that there is some signal handling that will work.
    >
    > But what? Which is where you came in.
    >
    > The situation is that most things that seem to work do actually work,
    > in some environments and under some circumstances. You can never be
    > sure when they will stop working, however, and all bets are off when
    > you port signal handling code to a new system. And, really but REALLY,
    > do not mix it with very high levels of optimisation or rely on it
    > being in any way thread safe.
    >
    > I can't tell you whether the code of Queue is intended to work if an
    > active Queue.get is interrupted by a signal which then does a Queue.put,
    > but that is the sort of circumstance where things get very hairy. Even
    > if Python has code to enable that case, it won't be 100% reliable on all
    > systems.
    >
    > Sorry. But that is the situation :-(
    >
    >
    > Regards,
    > Nick Maclaren.


    Fair, I'll find a way around then.

    Regards,

    hg
    hg, Jan 18, 2007
    #3
    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. Michael Pronath
    Replies:
    1
    Views:
    1,166
    Diez B. Roggisch
    Jan 3, 2005
  2. Jack Orenstein

    threading.Thread vs. signal.signal

    Jack Orenstein, Sep 18, 2005, in forum: Python
    Replies:
    0
    Views:
    463
    Jack Orenstein
    Sep 18, 2005
  3. Weng Tianxiang
    Replies:
    2
    Views:
    658
    Jonathan Bromley
    Jan 30, 2007
  4. Nicolas Moreau
    Replies:
    9
    Views:
    3,138
  5. Casey Hawthorne
    Replies:
    1
    Views:
    712
    Arne Vajhøj
    Mar 18, 2009
Loading...

Share This Page