On Thu, Sep 4, 2014 at 9:05 AM, Heikki Linnakangas <hlinnakan...@vmware.com> wrote: > Hmm. Perhaps we should call drainSelfPipe() only after poll/select returns > saying that there is something in the self-pipe. That would be a win > assuming it's more common for the self-pipe to be empty.
Couldn't hurt. >> But my >> impression was that those platforms were somewhat obscure. Could we >> have a separate latch implementation for platforms where we know that >> system calls will get interrupted by signals? > > ... and have ppoll or pselect. Yeah, seems reasonable, assuming that > ppoll/pselect is faster. 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. >> Alternatively, should >> we consider reimplementing latches using semaphores? I assume having >> the signal handler up the semaphore would allow the attempt to down >> the semaphore to succeed on return from the handler, so it would >> accomplish the same thing as the self-pipe trick. > > I don't think there's a function to wait for a file descriptor or semaphore > at the same time. Oh, good point. So that's out, then. -- 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
