Generally, tasks in the same TaskManager instance were all created by the same object, and their class is, or could be, an inner class in that object, and therefore they *could* talk to each through methods in that object.
I'm not sure the current runAfter mechanism is right for all the uses to which it is being put. My inclination is a gradualist approach, in which as we modify TaskManager uses to java.util.concurrent we look at the runAfter motivations and write code to implement them. If multiple uses have similar needs, we can abstract out the solution and share it. One candidate I've been thinking about is a Map<T,List<RunnableWithKey<T>>> where RunnableWithKey<T> objects have a method "T getKey()" and instances with the same key run in order of arrival. Patricia On 7/7/2011 7:00 AM, Gregg Wonderly wrote:
Can we institute a "call back" mechanism to handle this issue in a way that allows the "dependent" code to be run from the "after" task so that the serialization of the work is explicitly specified? Having a failed announcement come back might be appropriate too. It seems like runAfter() doesn't allow for the tasks to talk to each other about whether progress was made to allow the next step to proceed with any chance of success. Something like the following might be appropriate. public interface ExecuteAfter extends Runnable { public void failed( Throwable ex, Object dependent ); } Gregg On 6/26/2011 3:23 PM, Peter Firmstone wrote:There's an interesting thread of discussion in the Porter mail archive that Mark has uploaded for us (see River-311), relating to the TaskManager. Here's a very interesting comment from Bob Scheifler: Over the years we've been slowly eliminating use of Task.runAfter, and in any overhaul I'd prefer to finish that job rather than perpetuate it. I have in a past life been a fan of deadline scheduling. Any thoughts? Cheers, Peter.
