Look into dropping channel abstraction about libfuse HOT 4 CLOSED

Having looked into this a bit more, the situation is this:

From the API, it may appear as if every fuse session (struct fuse_session) is associated with a single fuse channel (struct fuse_chan) that is created by fuse_mount() and assigned to the session in fuse_session_add_chan(). Therefore, one may wonder why there are two separate structs in the first place, and why the channel structure has a reference counter and mutex.

The answer is that when using the multi-threaded session loop with the clone_fd option enabled, there are actually multiple channel objects per session. The session only holds a reference to the first one, and the additional channel objects don't actually hold references to the session object -- but they still exist. The additional channels are created by duplicating the fd (in fuse_clone_chan(), called by fuse_loop_start_thread). When processing a request, fuse_session_process_buf() records the active channel in the request object (struct fuse_req) so that it can be retrieved by e.g. the fuse_reply_* functions. Since the request object can potentially live longer than the worker thread that created it, we need to keep a reference count for the channel.

The reason for not having references to the session object from the extra channels is not clear, but with the current implementation this would not work because fuse_session_remove_chan always attempts to remove the channel from the session.

from libfuse.

So in other words, although the implementation makes sense, it is rather confusing. I think it would be better to merge struct fuse_chan into struct fuse_session (because there is always exactly one channel object associated with one session object with pointers in both directions), and then use a reduced struct fuse_chan only for the additional channels created by fuse_loop_mt (in particular, remove the session reference which is always null anyway).

This would also allow us to remove the fuse_session_add_chan and fuse_session_remove_chan functions which are rather pointless, since there is only ever one channel per session - so we may just as well create and destroy the channel together with the session.

from libfuse.

Another thought:

At the moment, the only channel that's accessible to the user application is the "master" channel that's stored in struct fuse_session. The per-worker channels are stored in the worker array and the struct fuse_req objects (so that they can be used by the fuse_reply_* functions), but there is no public API for them. So even though libfuse currently has several API functions that take struct fuse_chan parameters (notably all the fuse_lowlevel_notify_* functions), all these parameters can be replaced by struct fuse_session - because the channel that's embedded in there is the only one that the client application could pass anyway.

from libfuse.

This has been fixed in commit 5698ee0.

from libfuse.