threading and signals - main thread solely responsible for signal handling?

[exarkun at twistedmatrix.com]

On 04:43 pm, maligree at gmail.com wrote:
>The main part of my script is a function that does many long reads
>(urlopen, it's looped). Since I'm hell-bent on employing SIGINFO to
>display some stats, I needed to run foo() as a seperate thread to
>avoid getting errno 4 (interrupted system call) errors (which occur if
>SIGINFO is received while urlopen is setting itself up/waiting for a
>response). This does the job, SIGINFO is handled without ever brutally
>interrupting urlopen.
>
>The problem is that after starting foo as a thread, my main thread has
>nothing left to do - unless it receives a signal, and I am forced to
>keep it in some sort of loop so that ANY signal handling can still
>occur. I thought I'd just occupy it with a simple while 1: pass loop
>but that, unfortunately, means 100% CPU usage.
>
>Is there any way I could put the main thread to sleep? Or perhaps my
>approach is totally wrong?

I don't think those two options are mutually exclusive. ;)

MRAB suggested you time.sleep() in a loop, which is probably fine. 
However, if you want to have even /less/ activity than that in the main 
thread, take a look at signal.pause().

Also, perhaps not terribly interesting, signal.siginterrupt() was 
recently introduced, which will let you avoid EINTR if SIGINFO is 
received while urlopen is in a syscall (but will also prevent the signal 
from being handled until the syscall returns on its own).

And there's always Twisted & friends. :)

Jean-Paul