Hi Yann,
Am 17.03.23 um 15:11 schrieb Yann Ylavic:
On Fri, Mar 17, 2023 at 2:30 PM Rainer Jung <rainer.j...@kippdata.de> wrote:
Am 17.03.23 um 14:12 schrieb Yann Ylavic:
On Fri, Mar 17, 2023 at 11:20 AM Rainer Jung <rainer.j...@kippdata.de> 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
