8fc7062605
FUSE2 has compared to FUSE3 a rather complicated structure with respect to the FUSE loop, as it uses two handles for the loop and the mount. Due to needing the possibility to invalidate inodes during the session and to exit the FUSE session, the session and channel handles need to be kept alive. When the session stops, and with that the FUSE session too, the FUSE thread must still be able to unmount the FUSE mount. But due to FUSE2's annoying structure, the FUSE session must be destroyed before doing this. In this time period, where the FUSE2 loop stops running and between stopping the FUSE2 session, it cannot answer any requests. As a result, the "path test", where the mount path is poked cannot be performed. This "path test" is however necessary to ensure, that the FUSE loop exits. So, the main thread pokes at the FUSE mount to ensure the loop definitely exits to then signal the FUSE thread, that it can destroy the session and channel object. But at the same time, the FUSE loop may already exited and wait for the main thread to be signalled, that it can destroy the session and channel object. The waiting conditions here cannot be satisfied, leading to a deadlock. Fix this situation, by already signalling the FUSE thread, that it can destroy the FUSE objects, after calling fuse_session_exit. |
||
---|---|---|
.. | ||
test | ||
client_cliprdr_file.c | ||
client_rails.c | ||
client.c | ||
CMakeLists.txt | ||
cmdline.c | ||
cmdline.h | ||
file.c | ||
geometry.c | ||
smartcard_cli.c |