Hi all,
I thought a little bit about what it means to have both synchronous and
asynchronous APIs at the file system layer. Some questions come up:
* What does it mean for clients: does each client need to be aware
of both API variants ? How do clients pick any variant? It seems like if
we offer dual sync/async natures, that duplicate concept would bubble up
through all our architecture, which does not seem desirable.
* What is the granularity of being synchronous / asynchronous? Can
a provider choose returning synchronously or asynchronously with each
call, or does it need to pick one strategy once and for all?
It's always possible to write a bridge between for an asynchronous API
to drive synchronous providers, or the other way round. But the benefit
of being synchronous or asynchronous in a particular situation can only
be leveraged if it bubbles up right into the application layer!
* Asynchronous APIs add considerable overhead for fast queries
(i.e. have at least one Thread switch for the callback, even if the
result is available immediately); also, in terms of system consistency
and resource locking, what kinds of locks can really be given up while
an asynchronous request is pending but before its result is in?
* Synchronous APIs add considerable overhead for slow queries
(i.e. explosion in the number of Threads in wait state, thus locking
Resources).
To be more concrete, let's look at the current primary EFS methods in
IFileStore that can be slow on a remote FS:
* Information Retrieval
* String[] childNames(int options, IProgressMonitor); //
and its relatives: childInfos(), childStores()
* IFileInfo fetchInfo(int options, IProgressMonitor);
* Manipulation
* void copy(IFileStore destination, int options,
IProgressMonitor);
* void delete(int options, IProgressMonitor);
* void mkdir(int options, IProgressMonitor);
* void move(IFileStore destination, int options,
IProgressMonitor);
* void putInfo(IFileInfo, int options, IProgressMonitor);
It certainly makes sense to have asynchronous variants of these, if the
provider is inherently asynchronous (like the ECF filetransfer API). But
how high would we allow this to bubble up, how would we treat requests
on the sychronous API if the provider is asynchronous or vice versa?
Any thoughts?
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
[email protected]
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
