From ccd1e2a278f2a34ad8b65daeb64f7b47330cd5d8 Mon Sep 17 00:00:00 2001 From: ray Date: Wed, 22 Dec 2004 19:53:39 +0000 Subject: [PATCH] Added a note about one known weakness that arises from the wonderful complexity of asynchronous execution. git-svn-id: https://samskivert.googlecode.com/svn/trunk@1555 6335cc39-0255-0410-8fd6-9bcaacd3b74c --- .../samskivert/src/java/com/samskivert/util/Interval.java | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/projects/samskivert/src/java/com/samskivert/util/Interval.java b/projects/samskivert/src/java/com/samskivert/util/Interval.java index cbc6cc07..d5475cf6 100644 --- a/projects/samskivert/src/java/com/samskivert/util/Interval.java +++ b/projects/samskivert/src/java/com/samskivert/util/Interval.java @@ -139,6 +139,13 @@ public abstract class Interval return; } + // It's possible that we've been queued up on the RunQueue, and while + // we've been queued up the Interval was cancelled, rescheduled, and + // has fired again, in which case this run method will succeed even + // though it probably shouldn't. It's not the end of the world, + // this one will run and the new one that got queued up afterwards + // won't. I'm not sure if there's a way around that. + // increment expired and scoot everything back if we're getting too big _expired++; if (_expired > Integer.MAX_VALUE/2) {