Many signals may be the cause of -EINTR. It depends on what the signal
is as to how it's normally handled. sigalarm is the most common due to
it being a timer event.
Generate a timer that expires as fast as possible (not too fast to
prevent code execution), and you should see things left and right return
with -EINTR.
I'm very much aware of why SIGALRM is happening, I generate it and I
catch it. As per my original message on this thread, my program does
maintenance on a scheduled basis. The period of that maintenance is
many times per second.
Sooo... :)
Now let's get on with the story.
Libpq doesn't deal with system calls being interrupted in the slightest. None of the read/write or socket calls handle
anyerrors. Even benign
returns i.e. EINTR are treated as fatal errors and returned. Not to
malign, but there is no reason not to continue on and handle EINTR.
David
p.s. you cant use sleep() or alarm() functions and have a timer event as
well. The only POSIX compliant function that doesn't trample signal
timer events is nanosleep().
Brent Verner wrote:
On 25 Oct 2001 at 17:08 (-0400), David Ford wrote:
| I'm fresh in the code, but this has solved my issues with PQconnect*
| failing when interrupted by signals. Some of it is sloppy and not to my
| liking yet, but I'm still digging through to see if anything else needs
| touched. Comments appreciated.
Disclaimer: I may be wrong as hell ;-), but...
I'm not sure this is correct. I've tried to /make/ a SIGALRM cause
connect to errno==EINTR, but I can't cause this condition. I suspect
you have another signal being raised that is causing your symptom.
FTR, the textbook definition[1] of EINTR error for connect is:
The attempt to establish a connection was interrupted by delivery of a signal that was caught; the connection will be
established asynchronously.
Please check the attached prog to see if it is representative of your
code relating to the connect error you're seeing. If it is, please
run it and see if you can get it to cause the EINTR error from connect.
If you can't I'm more certain that you have a problem elsewhere.
cheers. brent
1. http://www.opengroup.org/onlinepubs/7908799/xns/connect.html
------------------------------------------------------------------------
[snipped]
