On Aug 11, 2008, at 8:44 AM, Jarek Gawor wrote:
So you want an executor to recognize somehow these special asynch
tasks and handle them appropriately (i.e. without assigning a
dedicated thread). Is that right?
Yes the ultimate goal is for the client to be notified of results when
an async method completes without having a client thread blocking (or
polling).
If so, why not define AsynchTask
interface (or something like that), e.g.:
AsynchTask {
start(AsynchResult h);
}
or (so that can be put on existing Runnable or Callable tasks)
AynchTask {
setAsynchResult(AsynchResult h);
}
With this the executor could recognize an asych task and just call
start() or run() or call() method (on the same or another thread) to
start the asynch task and create a special Future implementation that
would use the AsynchResult to get the result.
Is that what you are thinking or am I off in the weeds somewhere?
I'm not sure. One thing I don't think should be changed in the spec
is the async message signature, which is something like this:
Future<ReturnType> asyncMethod(Params);
I think having the async method return a Future is easy for users to
understand and is what other specs did (asyn-ws). Once we have a
future, I think the easiest and safest thing for a user to do is to
either block for the result, or schedule a task to be executed when
the future isDone. As for the exact interface for the task or the
scheduler, I don't have a strong preference other then I typically
lean towards using the already exiting spec interfaces (Callable and
ExecutorService).
-dain
