[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[eclipse-incubator-e4-dev] [resources] Asynchronous APIs for EFS
|
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