TLS, threads, and workers

[Roger Dingledine]

On Thu, Sep 04, 2003 at 11:04:31AM -0400, Bruce Montrose wrote:
> When you switch to threads, keep in mind that if one thread is handling
> signals such as SIGUSR1, etc. that other threads in the same process that
> are waiting via sleep(), select(), or poll() will also be interrupted. That
> is to say, that the sleep(), select(), or poll() will return prematurely.
> You should look at the revents field to see what value is returned by poll()
> in this case.

Yep. We've already had to deal with this, because poll() stops when you
suspend / resume the process. Our poll/select doesn't mind returning
early, and we don't ever sleep.

As for actually handling signals, apparently an arbitrary thread is
picked to receive the signal. But that's ok: we've already set things
up so signal handlers simply set a variable, and then the main loop
(in the main thread) will look at that variable periodically. So if you
get a signal, grab the "signal variables" lock, change the appropriate
variable, release the lock, and then go along your way.

stunnel seems to include some magic to make sure the appropriate thread
is the one that gets the signals. If that works, bonus.

Thanks,
--Roger