apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lucian Adrian Grijincu" <lucian.griji...@gmail.com>
Subject Re: apr_poll returns EINTR
Date Thu, 30 Aug 2007 01:15:22 GMT
On 8/30/07, Lucian Adrian Grijincu <lucian.grijincu@gmail.com> wrote:
> 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.

sorry for the miss informing mail, APR_STATUS_IS_TIMEUP(return code)
is the condition that must be checked after apr_poll ... but the rest
of the questions still remain.

> 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

Mime
View raw message