Re: svn commit: r1906889 - in /apr/apr/trunk: ./ build/ include/ include/arch/win32/ test/ threadproc/beos/ threadproc/netware/ threadproc/os2/ threadproc/unix/ threadproc/win32/

Hi Yann,

Am 17.03.23 um 15:11 schrieb Yann Ylavic:
> On Fri, Mar 17, 2023 at 2:30 PM Rainer Jung <[email protected]> wrote:
>>
>> Am 17.03.23 um 14:12 schrieb Yann Ylavic:
>>> On Fri, Mar 17, 2023 at 11:20 AM Rainer Jung <[email protected]> wrote:
>>>>
>>>> But: testpoll fails:
>>>>
>>>> testpoll            :  Line 897: apr_pollset_poll() didn't sleep
>>>>
>>>> Unfortunately I don't know when it started. Any idea, what I should
>>>> investigate?
>>>>
>>>> All this is on SLES11, haven't tried the recent APR trunk with newer
>>>> Linuxes, but r1908005 worked on them including testpoll tests.
>>>
>>> I suppose SLES11 is using epoll implementation, so r1902236 and
>>> r1902258 may help.
>>> Does your APR contain those?
>>>
>>> Regards;
>>> Yann.
>>
>> Yes, it contained everything until r1908442.
> 
> Hm OK, these commits were meant to address that precisely..
> It looks like SLES has some special epoll_wait() implementation that
> can return before the timeout. Could you printf the t2 - t1 diff in
> the justsleep() test after apr_pollset_poll()? It could be interesting
> to know if it's almost 200ms or close to zero (the latter could mean
> epoll_wait() does not block if there is no fd in the pollset, which is
> the case in this test).

The observed time delta on this platform is between 197 and 198.5 ms 
instead of somewhat above 200ms. I should note it is an old patch level 
of SLES 11 using kernel 2.6.32.12-0.7.

There are some old informations about the rounding of the timeout:

https://linux-fsdevel.vger.kernel.narkive.com/9jp0o6FA/bug-epoll-wait-timeout-is-shorter-than-requested

On this system HZ is 100, so a jiffie is 10ms and probably this means it 
should suffice to accept 200-10=190ms as the minimum sleep time.

Best regards,

Rainer