469,282 Members | 1,779 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,282 developers. It's quick & easy.

what can be used in a signal handler

hg
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

Jan 18 '07 #1
2 1325

In article <3z*******************@newsfe21.lga>,
hg <hg@nospam.orgwrites:
|>
|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.
Jan 18 '07 #2
hg
Nick Maclaren wrote:
>
In article <3z*******************@newsfe21.lga>,
hg <hg@nospam.orgwrites:
|>
|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
Jan 18 '07 #3

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

reply views Thread by Ravi Tallury | last post: by
2 posts views Thread by lpw | last post: by
3 posts views Thread by Martin McCormick | last post: by
3 posts views Thread by subnet | last post: by
11 posts views Thread by Jackie | last post: by
5 posts views Thread by Sontu | last post: by
4 posts views Thread by manochavishal | last post: by
10 posts views Thread by subramanian | last post: by
1 post views Thread by stalex | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by zhoujie | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.