Is EINTR a valid expectable value for apr_poll?
I'm running Ubuntu 7.04 with apr 127.
I expected three kinds of errors from this function
apr_status_t apr_poll ( apr_pollfd_t * aprset,
apr_int32_t numsock,
apr_int32_t * nsds,
apr_interval_time_t timeout
)
a) APR_SUCCESS - a descriptor was signaled in the interval specified
in timeout, no errors occurred.
b) APR_TIMEUP - the timeout interval expired and no descriptors were
signaled, all is still well, no errors occurred.
b) an error occurred: no mem, invalid args, memory faults, etc. This
cannot be recovered unless the wrong is repaired (mem is freed,
arguments are fixed, etc.)
I see that sometimes apr_poll returns EINTR.
All is well with the descriptors, pointers and memory.
In fact, reentering the call will result in a success / timeup
(depending on the status of the descriptors being polled).
Is this behavior expected? Should EINTR be returned, but APR_TIMEUP
not be set? I haven't checked for EINTR in my APR related code because
I've seen it's been silenced down in a couple of places
(reading/writing data in files/sockets).
If yes, could you point out a scenario where such a thing is necessary?
Furthermore, Windows cannot (or so I understood) return WSAEINTR:
"WSAEINTR A blocking Windows Socket 1.1 call was canceled through
WSACancelBlockingCall."
http://msdn2.microsoft.com/en-us/library/ms740141.aspx
And http://msdn2.microsoft.com/en-us/library/ms741547.aspx says The
WSACancelBlockingCall function has been removed in compliance with the
Windows Sockets 2 specification, revision 2.2.0.
This all means (to me) that the behavior of apr_poll is different on
Windows/Linux. If you cannot rely on one behavior, you have to check
for EINTR and call apr_poll again from the application if needed. IMHO
this only complicates code and adds no value.
--
Lucian Adrian Grijincu
