From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
Cc: | Andres Freund <andres(at)2ndquadrant(dot)com>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Escaping from blocked send() reprised. |
Date: | 2014-09-04 13:57:14 |
Message-ID: | CA+TgmoZvJeRDqxFuwQKStx6-F=O39kH4_y_yE1D-cztWxLMN4Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Sep 4, 2014 at 9:53 AM, Heikki Linnakangas
<hlinnakangas(at)vmware(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Shaun Thomas | 2014-09-04 14:09:17 | Re: PL/pgSQL 1.2 |
Previous Message | Robert Haas | 2014-09-04 13:54:37 | Re: Patch for psql History Display on MacOSX |