Re: Interruptible sleeps (was Re: CommitFest 2009-07: Yay, Kevin! Thanks, reviewers!) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Interruptible sleeps (was Re: CommitFest 2009-07: Yay, Kevin! Thanks, reviewers!)
Date
Msg-id 10061.1283978969@sss.pgh.pa.us
Whole thread Raw
In response to Re: Interruptible sleeps (was Re: CommitFest 2009-07: Yay, Kevin! Thanks, reviewers!)  (Martijn van Oosterhout <kleptog@svana.org>)
List pgsql-hackers
Martijn van Oosterhout <kleptog@svana.org> writes:
> If the issue is just that select() doesn't get interrupted and we don't
> care about a couple of syscalls, would it not be better to simply use
> sigaction to turn on SA_RESTART just prior to the select() and turn it
> off just after. Or are these systems so broken that select() won't be
> interrupted, even if the signal handler is explicitly configured to do
> so?

I think you mean turn *off* SA_RESTART.  We'd have to do that for each
signal that we were concerned about allowing to interrupt the select(),
so it's more than just two added calls.  Another small problem is that
the latch code doesn't/shouldn't know what handlers are active, and
AFAICS you can't use sigaction() to flip that flag without setting the
handler address too.  So while maybe we could do it that way, it'd be
pretty dang messy.

In my mind the main value of the Latch code will be to have a clean
platform-independent API for waiting.  Why all the angst about whether
the implementation underneath is clean or not?  It's more important that
it *works* and we don't have to worry about whether it will break on
platform XYZ.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: testing plpython3u on 9.0beta3
Next
From: Tom Lane
Date:
Subject: Postgres 9.0.0 release scheduled