On Mon, Mar 23, 2009 at 02:23:37PM +0100, Richter, J??rg wrote:
> Hi,
>
> Not really libevent specific, but perhaps someone here has seen this before
> and can help me with this one.
>
> The problem is that epoll_wait hangs longer than requested.
> This is a "strace -t -T -e epoll_wait" output of one such call:
>
> 12:07:08 epoll_wait(4, {{EPOLLIN, {u32=144477200, u64=144477200}}}, 1023,
> 2347024) = 1 <4575.649567>
>
> Here you see that the call takes 4575 seconds, but epoll_wait was only
> requested to wait 2347 seconds.
> epoll_wait would have waited longer, but fd activity made it return. Without
> fd activity it would have waited much longer.
> This is reproducible.
>
> Is there a maximum timeout epoll_wait can handle?
> Perhaps you have any other ideas what this might be?
Sorry for the delay. There is indeed a wart in (most? all) versions
of the Linux epoll implementation where the timeout maxes out at
(LONG_MAX - 999UL) / HZ milliseconds. If your long is 32 bits, and
your HZ is 1000, this tops out at a little over 2147 msec for you.
Libevent versions later than 1.4.4-stable work around this.
--
Nick
_______________________________________________
Libevent-users mailing list
[email protected]
http://monkeymail.org/mailman/listinfo/libevent-users