The proposed example is not what one should really do with signals, it is just for the purpose of studying.
Well remember this point it will prove important later: http://docs.python.org/dev/library/signal.html#signal.getsignal
There is no way to “block” signals temporarily from critical sections (since this is not supported by all Unix flavors).
The idea transforming a process as a pseudo hardware component
Signals are like wires normally that carries a rising edge. On low level architecture you may use a wire to say validate when results are safe to propagate. and a wire to clear the results.
I do a simple component that just sets to 1 the bit at the nth position of a register according to the position of the wire/signal (could be used for multiplexing).
Here is the code:
#!/usr/bin/env python3.3 import signal as s from time import sleep from time import asctime as _asctime from random import randint import sys asctime= lambda : _asctime()[11:19] class Processor(object): def __init__(self,signal_map, slow=False, clear_sig=s.SIGHUP, validate_sig=s.SIGCONT): self.cmd=0 self.slow=slow self.signal_map = signal_map self.clear_sig = clear_sig self.validate_sig = validate_sig self.value = 0 self._help = [ "\nHow signal are wired"] self._signal_queue =  self.current_signal=None if validate_sig in signal_map or clear_sig in signal_map: raise Exception("Dont wire twice a signal") def top_half(sig_no, frame): ## UNPROTECTED CRITICAL SECTION self._signal_queue.append(sig_no) ## END OF CRITICAL for offset,sig_no in enumerate(signal_map): s.signal(sig_no, top_half) self._help += [ "sig(%d) sets v[%d]=%d"%(sig_no, offset, 1) ] self._help += [ "attaching clearing to %d" % clear_sig] s.signal(clear_sig, top_half) self._help += [ "attaching validating to %d" % validate_sig ] s.signal(validate_sig,top_half) self._help = "\n".join( self._help) print(self._help) def bottom_half(self): sig_no = self._signal_queue.pop() now = asctime() seen = self.cmd self.cmd += 1 treated=False self.signal=None if sig_no in self.signal_map: offset=self.signal_map.index(sig_no) beauty = randint(3,10) if self.slow else 0 if self.slow: print("[%d]%s:RCV: sig%d => [%d]=1 in (%d)s" % ( seen,now,sig_no, offset, beauty )) sleep(beauty) self.value |= 1 << offset now=asctime() print("[%d]%s:ACK: sig%d => [%d]=1 (%d)" % ( seen,now,sig_no, offset, beauty )) treated=True if sig_no == self.clear_sig: print("[%d]%s:ACK clearing value" % (seen,now)) self.value=0 treated=True if sig_no == self.validate_sig: print("[%d]%s:ACK READING val is %d" % (seen,now,self.value)) treated=True if not treated: print("unhandled execption %d" % sig_no) exit(0) wired=Processor([ s.SIGUSR1, s.SIGUSR2, s.SIGBUS, s.SIGPWR ]) while True: s.pause() wired.bottom_half() sys.stdout.flush()Now, let's do some shell experiment:
$ ./signal_as_wire.py&  9332 660 jul@faith:~/src/signal 19:04:03 $ How signal are wired sig(10) sets v=1 sig(12) sets v=1 sig(7) sets v=1 sig(30) sets v=1 attaching clearing to 1 attaching validating to 18 660 jul@faith:~/src/signal 19:04:04 $ for i in 1 12 10 7 18 1 7 30 18; do sleep 1 && kill -$i %4; done 19:04:31:ACK clearing value 19:04:32:ACK: sig12 => =1 (0) 19:04:33:ACK: sig10 => =1 (0) 19:04:34:ACK: sig7 => =1 (0) 19:04:35:ACK READING val is 7 19:04:36:ACK clearing value 19:04:37:ACK: sig7 => =1 (0) 19:04:38:ACK: sig30 => =1 (0) 19:04:39:ACK READING val is 12
Everything works as it should, no? :) I have brilliantly used signals to transmit data asynchronously to a process. With 1 signal per bit \o/
What about «not being able to block the signal»
$ for i in 1 12 10 7 18 1 7 30 18; do echo "kill -$i 9455; " ; done | sh 22:27:06:ACK clearing value 22:27:06:ACK clearing value 22:27:06:ACK: sig7 => =1 (0) 22:27:06:ACK: sig30 => =1 (0) 22:27:06:ACK: sig10 => =1 (0) 22:27:06:ACK: sig12 => =1 (0) 22:27:06:ACK READING val is 15
Oh a race condition, it already appears with the shell launching the kill instruction sequentially: the results are out of order. Plus you can clearly notice my critical section is not small enough to be atomic. And I lost signals :/
Is python worthless?
Not being able to block your code, is even making a top half/bottom half strategy risky. Okay, I should have used only atomic operations in the top half (which makes me wonder what operations are atomic in python) such has only setting one variable and doing the queuing in the while loop, but I fear it would have been worse.
Which means actually with python, you should not play with signals such as defined in stdlib since without blocking you have systematical race conditions or you risk loosing signals if you expect them to be reliable.
I am playing with signals as I would be playing with a m68K interrupt (I would still block signal before entering the critical section). To achieve the blocking and processing of pending signals I would need POSIX.1 sigaction, sisget, sigprocmask, sigpending.
Why python does not support them (in the stdlib)?
Well python is running on multiple operating systems, some do support POSIX.1 some don't. As signals are not standardized the same way except for POSIX compliant systems with the same POSIX versions, therefore it should not be in st(andar)dlib. And since it is *that* risky I would advocate not allowing to put a signal handler at first place (except for alarm maybe). But, take your own risk accordingly :)
If you feel it is a problem, then just remember binding C code to python is quite easy, and that on POSIX operating system we have everything we need. This solution given in stackoverflow is funky but less than having unprotected critical section: http://stackoverflow.com/a/3792294/1458574.