[concurrency-interest] (no subject)

Iulian Mateias mateiasi at gmail.com
Mon Mar 27 03:35:31 EST 2006


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20060327/3feafa44/attachment.html


More information about the Concurrency-interest mailing list