(no subject)

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

(no subject)

Iulian Mateias
I'm new at this, but I believe that triggering (submitting) a repetitive task is intrinsically a "one way message" (caller->task) : you can't expect the task to 'return' something to the caller - it would yield a different result with every new execution. When you submit the task, the executor service can't produce a Future for each future (sic) execution of the task. It can only give you a fake Future, used solely for cancelling the repetitive task (if not cancelled, the task will be scheduled ad infinitum).

The Future, on the other hand, implements a two-way message passing protocol (caller->task and task->caller). Since every new execution produces a new result, which of these results would the caller need? A Future can hold a single result, while the caller probably needs all of them, so it makes sense to move the result processing code into the run() itself:

class RepetitiveTask implements Runnable {
 Callable<Result> realTask;
 ResultUser resultUser;
 .....
 .....
 public void run() {
  Result result = null;
  try {
   result = realTask.call ();
  }
  catch (Exception e) {
   resultUser.executionFailed (e); // (1)
  }
  if ( result != null )
   resultUser.use (result); // (2)
 }
}

If result processing is a lengthy operation which could mess up the scheduling of the task, you could have (1) and (2) dispatched as one-way, self-propelled messages (e.g., by submitting them to yet another executor).

I repeat, I'm new at this. If I'm wrong, please show me where.

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest