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

On 09/06/2010 08:46 PM, Tom Lane wrote:
> Well, it's not defined in the Single Unix Spec, which is our customary
> reference for portability.

FWIW, I bet the self-pipe trick isn't mentioned there, either... any
good precedence that it actually works as expected on all of the target
platforms? Existing users of the self-pipe trick?

(You are certainly aware that pselect() is defined in newer versions of
POSIX).

> Also, it's alleged that some platforms have
> it but in a form that's not actually any safer than select(). For
> example, I read in the Darwin man page for it
>
> IMPLEMENTATION NOTES
> The pselect() function is implemented in the C library as a wrapper
> around select().

Ouch. Indeed, quick googling reveals the following source code for Darwin:

http://www.opensource.apple.com/source/Libc/Libc-391.5.22/gen/FreeBSD/pselect.c

Now that you are mentioning it, I seem to recall that even glibc had a
user-space "implementation" of pselect. Fortunately, that's quite some
years ago.

> and that man page appears to be borrowed verbatim from FreeBSD.

At least FreeBSD seems to have fixed this about 8 months ago:
http://svn.freebsd.org/viewvc/base?view=revision&revision=200725

Maybe Darwin catches up eventually?

AFAICT the custom select() implementation we are using for Windows could
easily be changed to mimic pselect() instead. Thus most reasonably
up-to-date Linux distributions plus Windows certainly provide a workable
pselect() syscall. Would it be worth using pselect() for those (and
maybe others that support pselect() appropriately)?

> It's just two handles per process.

Good. How about syscall overhead? One more write operation to the
self-pipe per signal from within the signal handler and one read to
actually clear the 'ready' state of the pipe from the waiter portion of
the code, right?

Do we plan to replace all (or most) existing internal signals with these
latches to circumvent the interruption problem? Or just the ones we need
to wait for using pg_usleep()?

For Postgres-R, I'd probably have to extend it to call select() not only
on the self-pipe, but on at least one other socket as well (to talk to
the GCS). As long as that's possible, it looks like a more portable
replacement for the pselect() variant that's currently in place there.

Regards

Markus