[
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,
the similarity between Job and Future is in fact a very
interesting point.
I hadn't thought about it this way
before.
IMO the main difference between Job and Future is that
clients of a Job
expect that some workload gets scheduled and executed (in
run()) at
some point.
For a Future, on the other hand, clients just expect that
it gets "magically
completed by somebody somehow". Futures don't make any
assumption
about who's going to set the result and how.... so there is
not necessarily
the need for a ThreadPool or something. Think of a
client/server message
passing API, any incoming message can lead to a status
change (or
incoming data) which can set some Future to
completed.
It might in fact be possible that Jobs are used in a
similar way. Jobs have
a status (waiting, pending,...) and if a Job never gets to
the "Running"
state it might perhaps also get "magically completed"
somehow.
I'm not sure, though, whether it would be a good idea to
blur the concepts
that way.
Cheers,
--
Martin Oberhuber, Senior Member of Technical
Staff, Wind River
Target Management Project
Lead, DSDP PMC Member
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.
John
Martin 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 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
