[
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)
|
BTW, I'm still iffy on async APIs in general. Unfortunately I've been
tied down the last couple of weeks and missed most of the discussion
thread. I'll go back and review it.
What I have been doing is spending a lot of time in p2 land. Obviously
everything is async there since you are installing from remote servers
usually, or a slow DVD drive. But in p2, we deal with that using Jobs
and progress monitors. Is that not sufficient or is something you guys
have already dismissed. Again I apologize for missing the previous
e-mails, and fee free to blow me off :)
Doug.
> -----Original Message-----
> From: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx
> [mailto:eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx] On
> Behalf Of Oberhuber, Martin
> Sent: Thursday, October 30, 2008 4:47 PM
> To: E4 developer list
> Subject: [eclipse-incubator-e4-dev] Asynchronous
> Infrastructure (was: EFS,ECF and asynchronous)
>
> 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 base infrastructure should
> be in Equinox. Is anyone from the Equinox team listening and
> could guide through their 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: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx
> > [mailto:eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx] On Behalf Of
> > Scott Lewis
> > Sent: Wednesday, October 29, 2008 7:06 PM
> > To: E4 developer list
> > Subject: Re: [eclipse-incubator-e4-dev] [resources] EFS, ECF and
> > asynchronous
> >
> > Hi Martin,
> >
> > Oberhuber, Martin wrote:
> > > Hi Scott,
> > >
> > > to me, Futures and Listeners don't need to be a contradiction.
> > >
> >
> > 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.
> >
> > > 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.
> > >
> >
> > 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.
> >
> > > The problems that I have seen with callbacks in our
> products in the
> > > past are listed on
> > >
> >
> http://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 only
> > > provides 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);
> > > 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
> the kinds 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.
> > >
> >
> > 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.
> >
> > Scott
> >
> >
> >
> > > Cheers,
> > > --
> > > 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
> > > eclipse-incubator-e4-dev@xxxxxxxxxxx
> > > https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
> > >
> >
> > _______________________________________________
> > eclipse-incubator-e4-dev mailing list
> > eclipse-incubator-e4-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
> >
> _______________________________________________
> eclipse-incubator-e4-dev mailing list
> eclipse-incubator-e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
>
