471,853 Members | 1,625 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,853 software developers and data experts.

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 1399

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
NeoPa
reply views Thread by NeoPa | last post: by
reply views Thread by YellowAndGreen | last post: by
aboka
reply views Thread by aboka | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.