Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> writes:
> On 19/08/10 16:38, Tom Lane wrote:
>> Considering that pg_usleep is implemented with select, I'm not following
>> what you mean by "replace pg_usleep() with select()"?
> Instead of using pg_usleep(), call select() directly, waiting not only
> for the timeout, but also for data to arrive on the "self-pipe". The
> signal handler writes a byte to the self-pipe, waking up the select().
> That way the select() is interupted by the signal arriving, even if
> signals per se don't interrupt it. And it closes the race condition
> involved with setting a flag in the signal handler and checking that in
> the main loop.
Hmm, but couldn't you still do that inside pg_usleep? Signal handlers
that do that couldn't know if they were interrupting a sleep per se,
so this would have to be a backend-wide convention.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
