what can be used in a signal handler

[hg]

Nick Maclaren wrote:

> 
> In article <3zKrh.30692$sE7.26486 at newsfe21.lga>,
> hg <hg at nospam.org> 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