You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Jim Jagielski <ji...@jaguNET.com> on 2017/01/10 14:35:13 UTC
testpoll
Occasionally, I get:
testpoll : /Line 816: expected <0>, but saw <4>
Anyway I could easily see what test, exactly, is failing?
./testall -v testpoll does nil.
Re: testpoll
Posted by Rainer Jung <ra...@kippdata.de>.
Am 10.01.2017 um 16:20 schrieb Rainer Jung:
> Am 10.01.2017 um 15:35 schrieb Jim Jagielski:
>> Occasionally, I get:
>>
>> testpoll : /Line 816: expected <0>, but saw <4>
>>
>> Anyway I could easily see what test, exactly, is failing?
>> ./testall -v testpoll does nil.
>
> Depending on which version of APR you are testing, it should be line 816
> of file test/testpoll.c, e.g. in 1.5.x and 1.6.x HEAD:
>
> ...
> 815 rv = apr_pollset_poll(pollset, -1, &num, &descriptors);
> 816 ABTS_INT_EQUAL(tc, APR_SUCCESS, rv);
> 817 ABTS_INT_EQUAL(tc, 1, num);
> ...
>
> checking the return code of the apr_pollset_poll() call in 815 against
> APR_SUCCESS. So I guess the expected <0> is APR_SUCCESS and the real
> return code was 4.
But maybe your line numbers in testpoll.c differ, because return value 4
seems to not make much sense.
Regards,
Rainer
Re: testpoll
Posted by Rainer Jung <ra...@kippdata.de>.
Am 10.01.2017 um 16:20 schrieb Rainer Jung:
> Am 10.01.2017 um 15:35 schrieb Jim Jagielski:
>> Occasionally, I get:
>>
>> testpoll : /Line 816: expected <0>, but saw <4>
>>
>> Anyway I could easily see what test, exactly, is failing?
>> ./testall -v testpoll does nil.
>
> Depending on which version of APR you are testing, it should be line 816
> of file test/testpoll.c, e.g. in 1.5.x and 1.6.x HEAD:
>
> ...
> 815 rv = apr_pollset_poll(pollset, -1, &num, &descriptors);
> 816 ABTS_INT_EQUAL(tc, APR_SUCCESS, rv);
> 817 ABTS_INT_EQUAL(tc, 1, num);
> ...
>
> checking the return code of the apr_pollset_poll() call in 815 against
> APR_SUCCESS. So I guess the expected <0> is APR_SUCCESS and the real
> return code was 4.
OK, at least on RHEL 6 errno 4 is EINTR.
Regards,
Rainer
Re: testpoll
Posted by Yann Ylavic <yl...@gmail.com>.
On Wed, Jan 11, 2017 at 10:20 PM, Yann Ylavic <yl...@gmail.com> wrote:
> On Wed, Jan 11, 2017 at 10:17 PM, Yann Ylavic <yl...@gmail.com> wrote:
>> On Wed, Jan 11, 2017 at 10:05 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>>> On Wed, Jan 11, 2017 at 2:51 PM, Jim Jagielski <ji...@jagunet.com> wrote:
>>>> It looks like it is taking time for the message to
>>>> arrive and that is what is causing the APR_EINTR. After
>>>> all, it is behaving exacting like a wait for no data.
>>>> The apr_sleep() "ensures" time.
>>>
>>> But isn't -1 'infinite' wait, by definition?
>>
>> I think Jim's patch is about the message sent not reaching the read
>> size of the socket before poll() is call, hence the wakeup applies.
>
> Sorry, if your parser failed, s/size/side/ and s/call/called/ ;)
For test fairness (i.e. when both data and wakeup are available, data
win), I think the sleep should come after the wakeup, otherwise the
test might pass because the wakeup is not there yet (though less
likely to happen with pipe than with a socket).
Re: testpoll
Posted by Yann Ylavic <yl...@gmail.com>.
On Wed, Jan 11, 2017 at 10:17 PM, Yann Ylavic <yl...@gmail.com> wrote:
> On Wed, Jan 11, 2017 at 10:05 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>> On Wed, Jan 11, 2017 at 2:51 PM, Jim Jagielski <ji...@jagunet.com> wrote:
>>> It looks like it is taking time for the message to
>>> arrive and that is what is causing the APR_EINTR. After
>>> all, it is behaving exacting like a wait for no data.
>>> The apr_sleep() "ensures" time.
>>
>> But isn't -1 'infinite' wait, by definition?
>
> I think Jim's patch is about the message sent not reaching the read
> size of the socket before poll() is call, hence the wakeup applies.
Sorry, if your parser failed, s/size/side/ and s/call/called/ ;)
Re: testpoll
Posted by Yann Ylavic <yl...@gmail.com>.
On Wed, Jan 11, 2017 at 10:05 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> On Wed, Jan 11, 2017 at 2:51 PM, Jim Jagielski <ji...@jagunet.com> wrote:
>> It looks like it is taking time for the message to
>> arrive and that is what is causing the APR_EINTR. After
>> all, it is behaving exacting like a wait for no data.
>> The apr_sleep() "ensures" time.
>
> But isn't -1 'infinite' wait, by definition?
I think Jim's patch is about the message sent not reaching the read
size of the socket before poll() is call, hence the wakeup applies.
Re: testpoll
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Wed, Jan 11, 2017 at 2:51 PM, Jim Jagielski <ji...@jagunet.com> wrote:
> It looks like it is taking time for the message to
> arrive and that is what is causing the APR_EINTR. After
> all, it is behaving exacting like a wait for no data.
> The apr_sleep() "ensures" time.
But isn't -1 'infinite' wait, by definition?
Re: testpoll
Posted by Jim Jagielski <ji...@jaguNET.com>.
It looks like it is taking time for the message to
arrive and that is what is causing the APR_EINTR. After
all, it is behaving exacting like a wait for no data.
The apr_sleep() "ensures" time.
> On Jan 11, 2017, at 2:31 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
> According to apr_pollset_poll (-1 is the wakeup timeout)
>
> Remarks
> APR_EINTR will be returned if the pollset has been created with
> APR_POLLSET_WAKEABLE, apr_pollset_wakeup() has been called while
> waiting for activity, and there were no signalled descriptors at the
> time of the wakeup call.
>
> Clearly -1 time has not expired.
>
> The test in question;
> rv = apr_pollset_wakeup(pollset);
> ABTS_INT_EQUAL(tc, APR_SUCCESS, rv);
>
> rv = apr_pollset_poll(pollset, -1, &num, &descriptors);
> ABTS_INT_EQUAL(tc, APR_SUCCESS, rv);
> ABTS_INT_EQUAL(tc, 1, num);
>
> So the lingering question is whether this is a general unix implementation bug
> or specific to OSX behavior.
>
>
>
> On Wed, Jan 11, 2017 at 7:22 AM, Jim Jagielski <ji...@jagunet.com> wrote:
>>
>> On my system, poll works.
>>
>>> On Jan 10, 2017, at 3:15 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>>>
>>> Hmmm... I knew this sounded familiar...
>>>
>>> https://daniel.haxx.se/blog/2016/10/11/poll-on-mac-10-12-is-broken/
>>>
>>> On Tue, Jan 10, 2017 at 9:46 AM, Jim Jagielski <ji...@jagunet.com> wrote:
>>>> I didn't realize it referred to the actual line number in the
>>>> source file... How dumb :)
>>>>
>>>> This is on OSX so I'm getting EINTR.
>>>>
>>>> Weird.
>>>>
>>>>> On Jan 10, 2017, at 10:20 AM, Rainer Jung <ra...@kippdata.de> wrote:
>>>>>
>>>>> Am 10.01.2017 um 15:35 schrieb Jim Jagielski:
>>>>>> Occasionally, I get:
>>>>>>
>>>>>> testpoll : /Line 816: expected <0>, but saw <4>
>>>>>>
>>>>>> Anyway I could easily see what test, exactly, is failing?
>>>>>> ./testall -v testpoll does nil.
>>>>>
>>>>> Depending on which version of APR you are testing, it should be line 816 of file test/testpoll.c, e.g. in 1.5.x and 1.6.x HEAD:
>>>>>
>>>>> ...
>>>>> 815 rv = apr_pollset_poll(pollset, -1, &num, &descriptors);
>>>>> 816 ABTS_INT_EQUAL(tc, APR_SUCCESS, rv);
>>>>> 817 ABTS_INT_EQUAL(tc, 1, num);
>>>>> ...
>>>>>
>>>>> checking the return code of the apr_pollset_poll() call in 815 against APR_SUCCESS. So I guess the expected <0> is APR_SUCCESS and the real return code was 4.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Rainer
>>>>
>>
Re: testpoll
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
According to apr_pollset_poll (-1 is the wakeup timeout)
Remarks
APR_EINTR will be returned if the pollset has been created with
APR_POLLSET_WAKEABLE, apr_pollset_wakeup() has been called while
waiting for activity, and there were no signalled descriptors at the
time of the wakeup call.
Clearly -1 time has not expired.
The test in question;
rv = apr_pollset_wakeup(pollset);
ABTS_INT_EQUAL(tc, APR_SUCCESS, rv);
rv = apr_pollset_poll(pollset, -1, &num, &descriptors);
ABTS_INT_EQUAL(tc, APR_SUCCESS, rv);
ABTS_INT_EQUAL(tc, 1, num);
So the lingering question is whether this is a general unix implementation bug
or specific to OSX behavior.
On Wed, Jan 11, 2017 at 7:22 AM, Jim Jagielski <ji...@jagunet.com> wrote:
>
> On my system, poll works.
>
> > On Jan 10, 2017, at 3:15 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> >
> > Hmmm... I knew this sounded familiar...
> >
> > https://daniel.haxx.se/blog/2016/10/11/poll-on-mac-10-12-is-broken/
> >
> > On Tue, Jan 10, 2017 at 9:46 AM, Jim Jagielski <ji...@jagunet.com> wrote:
> >> I didn't realize it referred to the actual line number in the
> >> source file... How dumb :)
> >>
> >> This is on OSX so I'm getting EINTR.
> >>
> >> Weird.
> >>
> >>> On Jan 10, 2017, at 10:20 AM, Rainer Jung <ra...@kippdata.de> wrote:
> >>>
> >>> Am 10.01.2017 um 15:35 schrieb Jim Jagielski:
> >>>> Occasionally, I get:
> >>>>
> >>>> testpoll : /Line 816: expected <0>, but saw <4>
> >>>>
> >>>> Anyway I could easily see what test, exactly, is failing?
> >>>> ./testall -v testpoll does nil.
> >>>
> >>> Depending on which version of APR you are testing, it should be line 816 of file test/testpoll.c, e.g. in 1.5.x and 1.6.x HEAD:
> >>>
> >>> ...
> >>> 815 rv = apr_pollset_poll(pollset, -1, &num, &descriptors);
> >>> 816 ABTS_INT_EQUAL(tc, APR_SUCCESS, rv);
> >>> 817 ABTS_INT_EQUAL(tc, 1, num);
> >>> ...
> >>>
> >>> checking the return code of the apr_pollset_poll() call in 815 against APR_SUCCESS. So I guess the expected <0> is APR_SUCCESS and the real return code was 4.
> >>>
> >>> Regards,
> >>>
> >>> Rainer
> >>
>
Re: testpoll
Posted by Jim Jagielski <ji...@jaguNET.com>.
On my system, poll works.
> On Jan 10, 2017, at 3:15 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
> Hmmm... I knew this sounded familiar...
>
> https://daniel.haxx.se/blog/2016/10/11/poll-on-mac-10-12-is-broken/
>
> On Tue, Jan 10, 2017 at 9:46 AM, Jim Jagielski <ji...@jagunet.com> wrote:
>> I didn't realize it referred to the actual line number in the
>> source file... How dumb :)
>>
>> This is on OSX so I'm getting EINTR.
>>
>> Weird.
>>
>>> On Jan 10, 2017, at 10:20 AM, Rainer Jung <ra...@kippdata.de> wrote:
>>>
>>> Am 10.01.2017 um 15:35 schrieb Jim Jagielski:
>>>> Occasionally, I get:
>>>>
>>>> testpoll : /Line 816: expected <0>, but saw <4>
>>>>
>>>> Anyway I could easily see what test, exactly, is failing?
>>>> ./testall -v testpoll does nil.
>>>
>>> Depending on which version of APR you are testing, it should be line 816 of file test/testpoll.c, e.g. in 1.5.x and 1.6.x HEAD:
>>>
>>> ...
>>> 815 rv = apr_pollset_poll(pollset, -1, &num, &descriptors);
>>> 816 ABTS_INT_EQUAL(tc, APR_SUCCESS, rv);
>>> 817 ABTS_INT_EQUAL(tc, 1, num);
>>> ...
>>>
>>> checking the return code of the apr_pollset_poll() call in 815 against APR_SUCCESS. So I guess the expected <0> is APR_SUCCESS and the real return code was 4.
>>>
>>> Regards,
>>>
>>> Rainer
>>
Re: testpoll
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
Hmmm... I knew this sounded familiar...
https://daniel.haxx.se/blog/2016/10/11/poll-on-mac-10-12-is-broken/
On Tue, Jan 10, 2017 at 9:46 AM, Jim Jagielski <ji...@jagunet.com> wrote:
> I didn't realize it referred to the actual line number in the
> source file... How dumb :)
>
> This is on OSX so I'm getting EINTR.
>
> Weird.
>
>> On Jan 10, 2017, at 10:20 AM, Rainer Jung <ra...@kippdata.de> wrote:
>>
>> Am 10.01.2017 um 15:35 schrieb Jim Jagielski:
>>> Occasionally, I get:
>>>
>>> testpoll : /Line 816: expected <0>, but saw <4>
>>>
>>> Anyway I could easily see what test, exactly, is failing?
>>> ./testall -v testpoll does nil.
>>
>> Depending on which version of APR you are testing, it should be line 816 of file test/testpoll.c, e.g. in 1.5.x and 1.6.x HEAD:
>>
>> ...
>> 815 rv = apr_pollset_poll(pollset, -1, &num, &descriptors);
>> 816 ABTS_INT_EQUAL(tc, APR_SUCCESS, rv);
>> 817 ABTS_INT_EQUAL(tc, 1, num);
>> ...
>>
>> checking the return code of the apr_pollset_poll() call in 815 against APR_SUCCESS. So I guess the expected <0> is APR_SUCCESS and the real return code was 4.
>>
>> Regards,
>>
>> Rainer
>
Re: testpoll
Posted by Jim Jagielski <ji...@jaguNET.com>.
I didn't realize it referred to the actual line number in the
source file... How dumb :)
This is on OSX so I'm getting EINTR.
Weird.
> On Jan 10, 2017, at 10:20 AM, Rainer Jung <ra...@kippdata.de> wrote:
>
> Am 10.01.2017 um 15:35 schrieb Jim Jagielski:
>> Occasionally, I get:
>>
>> testpoll : /Line 816: expected <0>, but saw <4>
>>
>> Anyway I could easily see what test, exactly, is failing?
>> ./testall -v testpoll does nil.
>
> Depending on which version of APR you are testing, it should be line 816 of file test/testpoll.c, e.g. in 1.5.x and 1.6.x HEAD:
>
> ...
> 815 rv = apr_pollset_poll(pollset, -1, &num, &descriptors);
> 816 ABTS_INT_EQUAL(tc, APR_SUCCESS, rv);
> 817 ABTS_INT_EQUAL(tc, 1, num);
> ...
>
> checking the return code of the apr_pollset_poll() call in 815 against APR_SUCCESS. So I guess the expected <0> is APR_SUCCESS and the real return code was 4.
>
> Regards,
>
> Rainer
Re: testpoll
Posted by Rainer Jung <ra...@kippdata.de>.
Am 10.01.2017 um 15:35 schrieb Jim Jagielski:
> Occasionally, I get:
>
> testpoll : /Line 816: expected <0>, but saw <4>
>
> Anyway I could easily see what test, exactly, is failing?
> ./testall -v testpoll does nil.
Depending on which version of APR you are testing, it should be line 816
of file test/testpoll.c, e.g. in 1.5.x and 1.6.x HEAD:
...
815 rv = apr_pollset_poll(pollset, -1, &num, &descriptors);
816 ABTS_INT_EQUAL(tc, APR_SUCCESS, rv);
817 ABTS_INT_EQUAL(tc, 1, num);
...
checking the return code of the apr_pollset_poll() call in 815 against
APR_SUCCESS. So I guess the expected <0> is APR_SUCCESS and the real
return code was 4.
Regards,
Rainer