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 Rainer;

On Mon, Mar 20, 2023 at 10:31 PM Rainer Jung <[email protected]> wrote:
>
> Am 17.03.23 um 15:11 schrieb Yann Ylavic:
> >
> > 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

Thanks for looking. Well, it seems that there is no guarantee of a
minimal timeout on this system.
There is something fishy though, the only change w.r.t. before is the
millisecond round _up_..

>
> 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.

Is there something I can #ifdef (or check at configure/run time) for
SLELS11 or the kernel? This would document in the test that a minimal
timeout is usually expected, but on this platform/kernel. Or I'll use
190ms for everyone, which looks "unfair".


Regards;
Yann.