Hi, Miklos:

On 8/9/16 11:52 PM, Miklos Szeredi wrote:

On Wed, Aug 10, 2016 at 5:26 AM, Enke Chen [off-list ref] wrote:

quoted

Hi, Miklos:

This patch adds the async option for the flush/release operation in FUSE.

The async flush/release option allows a FUSE-based application to be terminated
without being blocked in the flush/release operation even in the presence of
complex external interactions. In addition, the async operation can be more
efficient when a large number of fuse-based files is involved.

---
Deadlock Example:

    Process A is a multi-threaded application that interacts with Process B,
    a FUSE-server.


               UNIX-domain socket
    App (A)  -----------------------  FUSE-server (B)
       |                                   |
       |                                   |
       |                                   |
       +-----------------------------------+
               open/flush/release

Why would the fuse server want to communicate with the app (using
other than the filesystem)?

In this particular case, the other communication channel is used to coordinate
the allocation (with "open") and de-alocation (with "flush/release") of the
shared memory associated with the opened "file".

In general an application may have special handling for the "flush/release"
operation that involve external interactions with one or more other processes,
and that is where this "async" operation can help.

IMO it would be even better if the "async" operation can be made the default so
folks do not need to worry about this types of deadlocks.  From reading of the
code, it seems that FUSE does "async" release under certain conditions already.

Thanks.  -- Enke