HashedWheelTimer and changing system time

[Marc-André Laverdière]

I agree.
>From what I remember of my real-time systems class, they taught us
that timers in real-time systems should be more or less of a linked
list of deltas (you could probably use a tree representation for quick
inserts if you're worried about O(n) performance on inserts).

So, you would sleep() a little bit, then decrement the first delta
accordingly. Once that delta hits 0, you can fire the event and
dismiss that. The next delta is based on the previous one, so it
becomes the new head of the queue.
Very important to make it thread safe.

But that starts to look like NOT a hashed wheel. Maybe a new timer
implementation along those lines?

Marc-André LAVERDIÈRE
"Perseverance must finish its work so that you may be mature and
complete, not lacking anything." -James 1:4
mlaverd.theunixplace.com/blog

 /"\
 \ /    ASCII Ribbon Campaign
  X      against HTML e-mail
 / \



2010/6/29 "이희승 (Trustin Lee)" <trustin at gmail.com>:
> Thanks guys for a nice discussion and sorry for joining pretty late. :)
>
> Perhaps we could refactor HashedWheelTimer to use time differences (i.e.
> delay) instead of deadline so that monotonic clock source is not
> mandatory at all?  If I remember correctly, the reason why deadline is
> being used is to work around the race condition that leads the premature
> expiration of some timeouts.  To make proper changes, we need a very
> solid regression test that confirms the new implementation is ready for
> prime time.
>
> Trustin
> --
> what we call human nature in actuality is human habit
> http://gleamynode.net/
>
>
> _______________________________________________
> netty-users mailing list
> netty-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/netty-users
>