Re: Escaping from blocked send() reprised.

On 09/04/2014 04:37 PM, Robert Haas wrote:
> Hrm.  So we'd have to block SIGUSR1, check the flag, then use
> pselect() to temporarily unblock SIGUSR1 and wait, then on return
> again unblock SIGUSR1?  Doesn't seem very appealing.  I think changing
> the signal mask is fast on Linux, but quite slow on at least some
> other UNIX-like platforms.  And I've heard that pselect() isn't always
> truly atomic, so we might run into platform-specific bugs, too.  I
> wonder if there's a better way e.g. using memory barriers.
>
> WaitLatch: check is_set.  if yes then done.  otherwise, set signal_me.
> memory barrier.  recheck is_set.  if not set then wait using
> poll/select. memory barrier.  clear signal_me.
> SetLatch: check is_set.  if yes then done.  otherwise, set is_set.
> memory barrier.  check signal_me.  if set, then send SIGUSR1.

Doesn't work. No matter what you do, the process running WaitLatch might 
receive the signal immediately before it calls poll/select. The signal 
handler will run, and the poll/select call will then go to sleep. There 
is no way to do this without support from the kernel, that is why 
ppoll/pselect exist.

- Heikki