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

Hi,

On 09/06/2010 11:03 PM, Tom Lane wrote:
> I don't entirely see the point of opening ourselves up to the risk of
> using a pselect that's not safe under the hood.

It should be possible to reliably determine the platforms that provide
an atomic pselect(). For those, I'm hesitant to use a "trick", where
pselect() clearly provides a simpler and more "official" alternative.
Especially considering that those platforms form the vast majority for
running Postgres on.

What I'm most concerned about is the write() syscall within the signal
handler. If that fails for another reason than those covered, we miss
the signal. As Heikki points out in the comment, it's hard to deal with
such a failure.

Regarding the exact implementation, the positioning of drainSelfPipe in
Heikki's implementation seems strange to me. Most descriptions of the
self-pipe trick [1] [2] [4] put the drainSelfPipe() just after the
select(), where you can be sure there actually is something to read.
(Except [3], which recommends putting it inside the signal handler,
which I find even more frightening).

Maybe you can read more than one byte at a time in drainSelfPipe(), to
save some syscalls?

Talking about the trick itself again: I found a lot of descriptions and
mentioning of the self-pipe trick, but so far I only found an unknown
window manager [5] and the custom inetd that's mentioned in the LWN
article [4] which really use that trick. Digging deeper revealed that
there's a sigsafe library [6] as well as the bglibs [7] which both seems
to use the self-pipe trick as well (of which the later doesn't even care
about the write()'s return value in the signal handler). None of these
two libraries seems to be used in any project of relevance.

Overall I got the impression that people like to describe the trick,
because it sounds so nifty and clever. However, I'd feel more
comfortable if I knew there were some medium to large projects that
actually use that trick. But AFAICT not even Bernstein's qmail does.

> In any case, on most
> modern platforms poll() is preferable to any variant of select().

Only Linux provides a ppoll() variant. And poll() itself doesn't replace
pselect().

Overall, I'm glad this gets addressed. Note that this is a long standing
issue for Postgres-R and it's covered with a lengthy comment in its TODO
file [8].

Regards

Markus Wanner

[1] D. J. Bernstein, The self-pipe trick
http://cr.yp.to/docs/selfpipe.html

[2] Emile van Bergen, Avoiding races with Unix signals and select()
http://www.xs4all.nl/~evbergen/unix-signals.html

[3] Alex Pennace, Safe UNIX Signal Handling Tips
http://osiris.978.org/~alex/safesignalhandling.html

[4] LWN Article: The new pselect() system call, mentions the self-pipe
trick in a comment
http://lwn.net/Articles/176911/

[5] Karmen: a window manager
http://freshmeat.net/projects/karmen

[6] sigsafe library
http://www.slamb.org/projects/sigsafe/

[7] Bruce Guenter, one stop library package
http://untroubled.org/bglibs/

[8] Postgres-R TOOD entry
http://git.postgres-r.org/?p=Postgres-R;a=blob;f=src/backend/replication/TODO;h=7bfc37ee9629943b9ff052d571b9d933ab38a0a8;hb=HEAD#l12