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.
-Doug
