[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [eclipse-incubator-e4-dev] [resources] EFS, ECF and asynchronous
|
Hi Pawel,
Pawel Piech wrote:
Oberhuber, Martin wrote:
Hi Scott,
to me, Futures and Listeners don't need to be a contradiction.
What's more interesting to me, is how to deal with Progress.
When a Progress Monitor already exists for the client, then
using it makes a lot of sense even if the result is obtained
asynchronously:
final CBFuture<IFileStore[]> childrenF = myFileStore.list(myProgress);
childrenF.chain(new Callback() {
public void onDone(IStatus result) {
if (result.isOK()) {
handleResult(childrenF.get());
}
};
});
I'm using class "CBFuture" as an "enhanced Future" that allows
registering Callbacks. Using a Callback style of handling things,
or CBFuture.waitFor() remains up to the client. Note that I'm using a
"chain()" method to indicate that the Framework/Future could
allow chaining multiple callbacks such that one is exeucuted after
the other. Also note how the callback retrieves the result of
computation from the Future, and not from the callback itself.
In the DSF framework (in Device Debugging project) we introduced a
Query object to act as a bridge between the sync and async APIs. It
implements Future and is similar to Callable in usage, but it takes a
callback instead of returning a value. It is used as follows:
* class DataQuery extends Query<Data> {
* protected void execute(DataRequestMonitor<Data> rm) {
* rm.setData(fSlowService.getData());
* rm.done();
* }
* }
* * Executor executor = getExecutor();
* DataQuery query = new DataQuery();
* executor.execute(query);
* * try {
* Data data = query.get();
* } catch() {...}
Unfortunately, in our experience using this kind of bridge is very
dangerous unless a strict threading model is enforced. I.e. it is
very easy for the Query.execute() implementation to deadlock waiting
for the thread that called get(). We use annotations to identify in
which threads API methods can be called, but only as a documentation
tool. It would be much more powerful if there was some run time
checking involved.
I agree that the threading expectations for futures (if used) should be
well thought out and documented (actually the same is true for async
listeners for that matter). Further, I believe that the API has to
support some explicit notion of caller-controlled timeout...e.g.
http://www.eclipse.org/ecf/org.eclipse.ecf.docs/api/org/eclipse/ecf/core/util/IAsyncResult.html#get(long)
as well as perhaps some notion of default timeouts (for get()s).
What do you have in mind WRT run-time checking?
Thanks,
Scott