It seems to fit in conceptually with IStatus/multistatus/jobs approach (i.e. return IStatus something rather than throw exception). Making it an interface (rather than a class) allows multiple implementations (as Darin suggests), and it would require few changes to either existing IStatus/Multistatus or the existing Jobs api (I don't think).
One question: is OSGi doing anything (wrt standardization) of concurrent/asynchronous support? I'll take a look at the latest distributed services (119) spec, but the last time I saw it (before June) I don't recall anything about futures/etc.
Scott Darin Wright wrote:
The asynchronous viewer framework in debug was designed such that clients could implement futures using jobs, but did not require clients to use jobs. (And the debug platform itself uses jobs to implement its futures). Perhaps if the job framework was extensible such that clients could provide their own implementation of job scheduling/execution, then jobs would suffice.DarinJohn Arthorne/Ottawa/[EMAIL PROTECTED] Sent by: [EMAIL PROTECTED]10/31/2008 09:07 AM Please respond to E4 developer list <[email protected]> To E4 developer list <[email protected]> cc SubjectRe: [eclipse-incubator-e4-dev] Asynchronous Infrastructure (was: EFS, ECF and asynchronous)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? If not, the org.eclipse.core.jobs bundle could still perhaps be a home for such an API, since it obviously needs a backing thread pool implementation with support for progress monitors, etc. JohnMartin Oberhuber wrote on 10/30/2008 04:47:02 PM:Hi Scott, Pawel and all, it looks like this Thread has long left the resources/EFS aspect of things, and moved to a more general discussion about infrastructure for asynchronous coding patterns. I'd thus like to make the discussion more general. We seem to agree that there needs to be some base infrastructure for asynchronous coding patterns, and (perhaps even more important) API Documentation for how to properly use that infrastructure. If this base infrastructure is unified, we all win. Thanks Scott for volunteering to offer your expertise as well as contributions. What could be the next steps towards making it happen? I'm assuming that the baseinfrastructure should be in Equinox. Is anyone from the Equinox team listening and could guide throughtheir process for contribution? Assuming that Equinox is right, we should perhaps first find a proper place for this discussion; then argue about good infrastructure/patterns; these need to be backed by some actual usage somewhere. Right now, it looks like what we'll want is at least Future (aka RequestMonitor, AsyncExecutionResult) Callback (aka Listener) Status/MultiStatus (async variant) Executor/Queue/Realm (for posting async Runnables/Callbacks in a well-known Thread) along with some well-documented Exception types (cancellation, timeout) as well as Threading paradigm. How to proceed from here? Potential clients of async certainly include DD/DSF and ECF, perhaps Resources/EFS; who else is interested in infrastructure for async? Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm-----Original Message-----From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott LewisSent: Wednesday, October 29, 2008 7:06 PM To: E4 developer listSubject: Re: [eclipse-incubator-e4-dev] [resources] EFS, ECF and asynchronousHi Martin, Oberhuber, Martin wrote:Before my further comments...I don't believe they are in conflict either (that is, both can be used in some cases as described by Martin). I guess I sort of presented them as exclusive, but I didn't really mean to have it be so.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);I agree that the general issue of how to handle progress monitors is tricky. Although I accept your ideas above as a possible solution, I'm not sure whether this is the 'right' mechanism or not for 'remote progress monitoring'. I've been thinking about this for some time, but still don't feel like I have a good general solution for supporting IProgressMonitor for remote procedures.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.The problems that I have seen with callbacks in our productsin the past are listed onhttp://wiki.eclipse.org/E4/Pervasive_Themes#Becoming_More_Asynchronous* Much boilerplate code - Closures would be nice to avoid explosion of anonymous inner classes, which could cause bloat* Need clarification on what thread and in what context the callback will be called* When debugging, it is very hard to trace back the flow of operation across multiple callback invocations. It can even make debuging close to impossible unless some Tracing functionality for the callbacks is built into the Framework(we ended up doing this in our commercial product). * Exception handling needs to be clarified. Java6 Future onlyprovides Future#isCanceled(), that's not enough since the result of an operation might also be an exception. I'm introducint "Istatus result" above but that's also not optimal.I agree these are other issues...thanks.The synchronous variant needs more verbosity writing it than one would expect, because cancellation and errors (exceptions) need to be handled, wrapped and potentially re-wrapped with Futures:final CBFuture<IFileStore[]> childrenF =myFileStore.list(myProgress);Yes, I agree that these are issues. I also agree that it would be useful to have Equinox-specific impls of Future (which is really what the IAsyncResult interface was meant to be and can/will change to be if desired). Further, I've recently also realized that there also should probably be something like remote impls of IStatus/MultiStatus, as I've been doing some remote mgmt interfaces (i.e. accessing and managing a remote processes' OSGi framework, p2, etc)...and it's clear to me that it is going to be very helpful to support the usage of IStatus/Multistatus as return values, as well as exceptions in remote service access. I agree that Future/IAsyncResult as well as IStatus/Multistatus and exception types should be widely available (i.e. in Equinox rather than redone/available in many locations above Equinox). We (ECF) are willing to contribute (and modify as desired) what we've done in this area (e.g. IAsyncResult+impl, RemoteStatus/RemoteMultiStatus, exception types) as desired.try { handleResult(childrenF.get()); } catch(CancellationException e) { throw new OperationCancelledException(e); } catch(ExecutionExeption e) { throw new CoreException(new Status(/*.blabla*/)); }although that could perhaps be simplified if we declared some Eclipse specific implementation of Future which throws thekinds of Exceptions that we already know (like CoreException embedding an Istatus) instead of the JRE's ExecutionException that's really alien to our current code.ScottCheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm _______________________________________________ eclipse-incubator-e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev_______________________________________________ eclipse-incubator-e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev_______________________________________________ eclipse-incubator-e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev_______________________________________________ eclipse-incubator-e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev _______________________________________________ eclipse-incubator-e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
_______________________________________________ eclipse-incubator-e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
