On Wed, Sep 21, 2011 at 3:00 PM, Doug Lea <d...@cs.oswego.edu> wrote: > On 09/21/11 05:17, Aleksey Shipilev wrote: >> >> On Wed, Sep 21, 2011 at 1:12 PM, Aleksey Shipilev >> <aleksey.shipi...@gmail.com> wrote: >>> >>> On Tue, Sep 20, 2011 at 10:34 PM, Doug Lea<d...@cs.oswego.edu> wrote: >>> From the code perspective, it appears to be point change. >> >> I take that assertion back. I understand the Delayed elements which >> are using constant delays need to be carefully recalibrated after >> deserialization, which will probably require storing advanced metainfo >> (i.e. "absolute time-to-fire") in serialized form. > > Yes, this is what I was getting at. We try to avoid in j.u.c > any invisible conversions between relative and absolute time, > because they are filled with potential surprises; including > inconsistent clocks across machines, ntp adjustments, > resets of system clocks, and the difference in precision > between nanoTime and currentTimeMillis. And further, because > the "Delayed" elements in the queue are opaque to us, we cannot > automate any such conversions or adjustments anyway. > > If we had an AbsoluteDelayQueue, it would be a good candidate > for being serializable. > > But as it stands, anyone needing to transport delayed tasks across > machines can do so by iterating over the queue, and dealing > one-by-one with their own Delayed elements wrt the above issues.
That's one good explanation, thanks Doug! -Aleksey.
