On Thu, Sep 4, 2014 at 9:53 AM, Heikki Linnakangas <hlinnakan...@vmware.com> wrote: > 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.
Eesh, I was confused there: ignore me. I was trying to optimize away the signal handling but assuming we still had the self-pipe byte. But of course in that case we don't need to change anything at all. I'm going to go get some more caffeine. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
