Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse-incubator-e4-dev] [resources] EFS, ECF and asynchronous

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.

Cheers,
Pawel



Back to the top