Re: pthreads and poll

[Kaz Kylheku <kaz at ashi dot footprints dot net>]

On Thu, 20 Jan 2000 kd@flaga.is wrote:

> Date: Thu, 20 Jan 2000 16:32:40 +0000
> From: kd@flaga.is
> Reply-To: glibc-linux@ricardo.ecn.wfu.edu
> To: glibc-linux@ricardo.ecn.wfu.edu
> Cc: mu@flaga.is, bug-glibc@gnu.org
> Subject: pthreads and poll
> 
> Hi,
> 
> According to the man page for poll() it says it should return EINTR if a
> signal occurred before any of the requested poll events happened.
> Now I have the following threads,
> 
> 1) threadA is sleeping in poll
> 2) threadB signals a condition variable
> 
> As I understand, pthreads on linux use unix signals to signal threads
> although abstracted by pthreads.
> So my questions:
> 
> 1) Is it a bug that threadA (the one sleeping on poll) is not "interrupted"
> when a pthreads signal occurred?
> 2) If not, how can I make sure that threadA is woken up (interrupted) when
> a pthread signal occurred?

If I am to understand correctly, you expect the pthread_cond_signal
operation to unblock threadA even though threadA is  not waiting on that
condition variable.

That is simply unreasonable. The signalling of a condition should not affect
threads that are not waiting on that condition.

The signals used by LinuxThreads internally are directed at specific threads.
For example if you do pthread_cond_broadcast() then a resume signal is sent
to each thread that was waiting on the given condition variable, not to
other threads.

If you want to shut down the thread that is waiting in poll, what you can do is
pthread_cancel() it.  Have it call pthread_testcancel() whenever it wakes up,
since poll is not a cancellation point. LinuxThreads will do the job of waking
up the poll, but poll does not have a built in test for cancellation.

You can also use pthread_kill() to send specific signals to specific threads.