Skip to main content

[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
http://www.eclipse.org/dsdp/tm
 
 

Back to the top