On Tue, 23 Aug 2005 13:46:49 +0200
Matthias Drochner <M.Drochner@fz-juelich.de> wrote:

> The appended patch models the OSF1/Solaris behaviour -- somehow
> I like that most. My tests were successful so far.

If I understand, systems relying on the expectation of the old behavior,
that is, making sure that only one thread doesn't block the signal, can
still assume that only the intended thread gets awaken?  Or must they
now also use a conditional variable or such since other threads might
also awake?

I am asking because I have a system on one of my source trees assuming
that standard behavior, with a dedicated thread responsible for polling
descriptors, and since the standard POSIX threads API lacks the necessary
support to properly multiplex thread-friendly efficient events with
filedescriptor events, it relies on a special signal sent to the process
to add/remove descriptors from the set and such (and only that thread
gets the process-wide signal, not blocking it).  The signal handler is
a dummy stub (NOOP) and the goal is only to cause the polling thread's
main loop to reiterate (poll(2) then gets interrupted with EINTR).
This allows the implementation of PTH library-like
pth_poll_ev()/pth_connect_ev()/pth_accept_ev() equivalent functions but
using native POSIX threads...

The only other sane approach would have been to dedicate a special
AF_LOCAL/SOCK_DGRAM socketpair or the like to reception of such
interrupting events, which also could work, though.

This was because multiple threads polling on the same descriptor, caused
a random thread to be awaken, not all of them, similarily to reception of
a signal to the process if multiple threads were not blocking the signal,
so making sure that only the polling thread doesn't block the signal seemed
to be the way to go to make sure it was the one awaken...

Thanks,
Matt

-- 
Note: Please only reply on the list, other mail is blocked by default.
Private messages from your address can be allowed by first asking.