On Sun, Jul 01, 2007 at 12:11:26PM -0400, Tom Lane wrote:
> To me, this calls into question whether we should try to avoid using
> SA_RESTART at all. The reason for doing it of course is to avoid
> unexpected syscall EINTR failures as well as short read/short write
> behaviors during disk I/O.
Hrm, is there even a list of syscalls that are considered
restartable/interruptable?
> The only really clean solution I can see is to stop using SA_RESTART
> and try to make all our syscalls EINTR-proof. But the probability
> of bugs-of-omission seems just about 100%, especially in third party
> backend add-ons that we don't get to review the code for.
Not all syscalls can return EINTR and most of the ones that can are not
ones likely to be used by most backend addons. The problem is there
would be a transistion, which would suck. (All the calls that could
return EINTR have to be checked for other errors anyway, but still).
One other possiblity is using something like nanosleep():
Compared to sleep(3) and usleep(3), nanosleep() has the advantage of not affecting any signals, it is
standardizedby POSIX, it provides higher timing resolution, and it allows to continue a sleep that has been
interruptedby a signal more easily.
But I don't know if that would help on your HPUX box though...
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.
