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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to