Re: testpoll

[Yann Ylavic]

On Wed, Jan 11, 2017 at 10:20 PM, Yann Ylavic  wrote:
> On Wed, Jan 11, 2017 at 10:17 PM, Yann Ylavic  wrote:
>> On Wed, Jan 11, 2017 at 10:05 PM, William A Rowe Jr  
>> wrote:
>>> On Wed, Jan 11, 2017 at 2:51 PM, Jim Jagielski  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

[Yann Ylavic]

On Wed, Jan 11, 2017 at 10:17 PM, Yann Ylavic  wrote:
> On Wed, Jan 11, 2017 at 10:05 PM, William A Rowe Jr  
> wrote:
>> On Wed, Jan 11, 2017 at 2:51 PM, Jim Jagielski  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

[Yann Ylavic]

On Wed, Jan 11, 2017 at 10:05 PM, William A Rowe Jr  wrote:
> On Wed, Jan 11, 2017 at 2:51 PM, Jim Jagielski  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

[William A Rowe Jr]

On Wed, Jan 11, 2017 at 2:51 PM, Jim Jagielski  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

[William A Rowe Jr]

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, , );
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  wrote:
>
> On my system, poll works.
>
> > On Jan 10, 2017, at 3:15 PM, William A Rowe Jr  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  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  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, , );
> >>>   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

[Jim Jagielski]

On my system, poll works.

> On Jan 10, 2017, at 3:15 PM, William A Rowe Jr  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  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  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, , );
>>>   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

[Jim Jagielski]

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  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, , );
>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

[Rainer Jung]

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, , );
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

[Rainer Jung]

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, , );
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

[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, , );
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