Thanks a lot, that is a bit clearer, so the event loop will always
be controlling the first timer only, which is supposed to be the closest
to expiration (and some few next nodes) right ?

i m trying to avoid using start/stop or even ev_timer_again because the
socket is considered busy when taken by a thread and thread will hold the
socket for as long as clients have something to send which could be a lot of
info
or just a few bytes, i m trying to say that a thread may hold the socket
longer than the
idle time out so how can i manage
to prevent the event loop from disconnecting a socket that is being used
by another thread ? what i mean is, if every time the socket is taken by a
thread
i will update the timer to expire later (now() + timeout) and put it at the
end of the list, there is no way
for me to know how long the socket will be taken by the thread and thus busy
(not idle) ? (i would not like to use semaphores or mutexes, etc)

My background with timers is limited only to a few timers so i did not
mind to start/stop in the past, but this time that does not apply.

On 2 June 2011 20:59, Brandon Black <[email protected]> wrote:

> On Thu, Jun 2, 2011 at 9:08 PM, Juan Pablo L <[email protected]>
> wrote:
> > thanks for your reply, actually yes i have read the part about the Be
> smart
> > about timer,
> > but this is the first time i have to manage so many timers, and something
> is
> > not clear to me.
> >
> > #4 refers to making a linked list and putting all timers in there but how
> > can i control individually
> > each timer, [....]
>
> It works, as long as you maintain the list in timer order, which is
> O(1) if all the timeout intervals are the same.  When a connection
> enters its "connected" state where you want to start the idle timer,
> you simply add it to the tail of the list.  When a connection ends,
> you remove it from the list.  When a connection has an I/O event to
> reset the idle timer, you move it to the bottom of the list.
>
> The actual ev_timer is set for the time the head of the list needs to
> fire.  When it fires, you handle the connection at the head (and any
> more in list order within some small epsilon past the current
> ev_now()).  If "handling" the timeout at the top of the list means
> killing the connection, then it simply gets removed from the list.  If
> not, it goes to the bottom (e.g. a recurring maintenance timer
> per-connection, as opposed to an idle-kill timer).  At the end of the
> callback, you set the next timeout for the timer to the time of the
> new list head.
>
> The details can be tricky to implement and debug.  IMHO as the docs
> state, it's only worth it if you have a *ton* of identical timeouts.
> It would be neat if someone wrote a generic implementation in C that
> worked with arbitrary user-defined connection datatypes while keeping
> list management pointers inside them.
>
> -- Brandon
>
_______________________________________________
libev mailing list
[email protected]
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev

Reply via email to