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 18:00:10 GMT
On 8/30/07, Lucian Adrian Grijincu <lucian.grijincu@gmail.com> wrote:
> 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.
> >

OK I think I've figured it out for myself.
To not return EINTR would mean that APR should attempt to poll again
and return the next call's return code.

os_poll (original timeout)
if EINTR os_poll (original timeout - time_spent())

This is still invalid because the process might get preempted between
the moment in which the new timeout is calculated and the one in which
os_poll enters the kernel.

So, it must return EINTR as received from the os.

Case closed,
Lucian Adrian Grijincu

Mime
View raw message