threading and signals - main thread solely responsible for signalhandling?

[Maligree]

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?

 

[MRAB]

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?

The simplest fix is to call time.sleep(seconds) in the loop. Repeated
sleeps of 1 second, for example, consume very little CPU time.

 

[exarkun]

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