[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipse-incubator-e4-dev] Asynchronous Infrastructure (was: EFS, ECF and asynchronous)
|
Hi John,
Although I agree that jobs/IStatus are similar to futures, they
John Arthorne wrote:
There doesn't seem to be much difference between the future construct
you describe and the Job API. You can attach listeners to jobs which
seems to be the same as your Callback mechanism. Future.waitFor() is
the same as Job.join(), and Future.get() is similar to
Job.getResult(). I did actually have futures in mind when designing
the jobs API, with the job's "result" being the payload returned from
the asynchronous operation. I initially made this result of type
Object so clients could pass back whatever return value they wanted. I
then perhaps mistakenly switched the result type to IStatus, thinking
that clients could return sub-types of Status containing any result
object they wanted. This is why I specified almost nothing for the
return value of Job#run and Job#getResult, leaving it as a mechanism
for clients to communicate whatever they want back to the caller. In
reality it didn't end up being used this way, because people fell into
the common coding patterns around IStatus and just returned the usual
OK/ERROR results.
So, I'm wondering if there's something fundamental missing from Jobs
that makes these asynchronous coding patterns difficult, and is there
some incremental improvement we can make to Jobs to make it as
expressive and useful as your Future construct?
I think there probably are incremental improvements to make IStatus/Jobs
expressive as Futures. One thing would be a timeout mechanism...e.g.:
Object get(long timeToWait);
and I do think that the subclassing of IStatus (as way to get result of
appropriate type) seems to require more from clients than they are
generally willing to do.
But I agree that with modifications to IStatus+Jobs (to the degree
possible) it could get us much of the way there.
I think that one aspect that is likely to make futures more usable is to
allow clients to write things like this:
IFutureStatus futureStatus = foo.bar();
// store future result for later access...do stuff, etc.
MyResult r = (MyResult) futureResult.get(); // or something better
than 'get'...as well as get(long)
I think that if they have to do much/any more then it will make it
rather hard to get adoption.
Scott
