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

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