Re: [fuse-devel] libfuse: exiting fuse_session_loop

[Mike S. <ma...@gm...>]

On Tue, Jan 17, 2012 at 7:14 PM, Andrew Tomazos <an...@to...> wrote:
> Hey guys,
>
> (Context: Ubuntu 11.10 and libfuse 2.8.4-1.4ubuntu1 Linux
> 3.0.0-14-generic #23-Ubuntu SMP Mon Nov 21 20:28:43 UTC 2011 x86_64
> x86_64 x86_64 GNU/Linux)
>
> I'm trying to use libfuse. I want to cause fuse_session_loop to exit
> (from a signal handler or a different thread), but when I call
> fuse_session_exit nothing happens until the session receives a new
> request.
>
> fuse_session_exit sets a flag that is read by fuse_session_exited.
> Debugging into fuse_session_loop it appears to block on
> fuse_chan_recv, so it doesn't check fuse_session_exited again until
> the top of the loop...

I used to do something similar in my program. I had a thread running
fuse, and another thread that called fuse_exit() on the fuse structure
to set the flag. Since it doesn't actually quit until another event
comes in, I just had it try to open the mount point to cause an
immediate event. Eg:

fuse_exit(fuse structure);
fd = open(fuse mountpoint)
(fd should be -1 here, since we expect the fuse loop to exit and this
call to fail)

However, I have since changed this to just calling system("fusermount
-u -z " mountpoint) on Linux (and use unmount() on OSX) because the
fuse_exit() approach was leaking memory. This has since been fixed
here:

https://github.com/torvalds/linux/commit/5dfcc87fd79dfb96ed155b524337dbd0da4f5993

So that may or may not be a concern for you depending on your kernel
and how often you startup/shutdown your fs.

Additionally, if you plan to use helgrind to help find threading
issues in your fs, the fuse_exit() approach will generate a report
(which you can ignore with a suppression file). The fusermount
approach does not need a suppression file if you use a single-threaded
fuse loop.

Hope this helps!
-Mike