lkml.org 
[lkml]   [2016]   [Aug]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] FUSE: add the async option for the flush/release operation
From
Date
Hi, Miklos:

On 8/9/16 11:52 PM, Miklos Szeredi wrote:
> On Wed, Aug 10, 2016 at 5:26 AM, Enke Chen <enkechen@cisco.com> wrote:
>> 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

\
 
 \ /
  Last update: 2016-08-10 22:01    [W:0.076 / U:0.340 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site