Why doesn't CBFS Connect provide asynchronous versions of events?
When the OS sends a request to a filesystem, it expects that the filesystem will respond to it, either with the requested data or an error. From the OS's point of view, the virtual filesystems created using CBFS Connect are just like any other filesystem, so they must work the same way. While it may be possible to postpone responding to a filesystem request in some cases, you do eventually have to send a response back to the OS. Therefore, all events in CBFS Connect are synchronous.
Your application can employ various strategies for working around this, such as having your own pool of worker threads to send work to, but even this makes little sense since you'd still have the CBFS component's event handlers waiting on a response.
When you first mount the virtual filesystem, you specify a certain timeout that prevents the OS from being blocked forever. If your application needs more time to handle a request, you can call the ResetTimeout method from the event handler in order to extend the time given to your handler for processing. But again, keep in mind that whatever process the OS made the request on behalf of is still waiting for a response; you should always strive to complete event handlers as quickly as possible to prevent confusion and/or negative user experiences.
We appreciate your feedback. If you have any questions, comments, or suggestions about this article please contact our support team at firstname.lastname@example.org.