Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP: Add Multithreading Support #293

Open
wants to merge 8 commits into
base: master
Choose a base branch
from
Open

Conversation

volfco
Copy link

@volfco volfco commented Aug 20, 2024

Add Multithreading Support to fuser.

This implementation modifies BackgroundSession to accept a thread quantity. If this number is two or more, then n - 1 background workers will be created. There will always be a primary worker created, hence n - 1.

Session::worker is called to clone the Session, which in turn calls Channel::worker. This method accepts the Mount object, and using .session_fd to return the Session FD, fuse_fd_clone is invoked to clone the file descriptor and run the needed ioctl call to setup the session.

I can't take all the credit, as the main piece of code in channel.rs is from the Datenlord project where they are doing a native async_fuse library.

The code in question is from here: https://github.com/datenlord/datenlord/blob/d90fd43732373451207e56e9b9cd7eef9e7b53e1/src/async_fuse/fuse/session.rs#L73

Additional References:

TODO

  • Clean up feature gate
  • Add more function documentation
  • Add changelog entry
  • Bump version

@@ -291,7 +291,7 @@ impl KernelConfig {
/// implementations are provided here to get a mountable filesystem that does
/// nothing.
#[allow(clippy::too_many_arguments)]
pub trait Filesystem {
pub trait Filesystem: Clone {
Copy link
Contributor

@colinmarc colinmarc Sep 5, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the random drive-by comment. In my opinion, it would be better to require Send + Sync instead of Clone, and change the trait methods to take non-mutable self. Then it's up to the user how they handle mutability, if they need it. Cloning + mutability is a massive footgun.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the feedback!

I need to figure out exactly what you're referring to and understand it, but that does make sense and does seem better. Something fun to do this weekend!

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if a type is Send, it can be safely moved between threads.

if a type is Sync, it can be safely shared between threads.
see https://doc.rust-lang.org/nomicon/send-and-sync.html?highlight=Send#send-and-sync

struct SimpleFS {
data_dir: String,
next_file_handle: AtomicU64,
next_file_handle: Arc<AtomicU64>,
Copy link
Contributor

@colinmarc colinmarc Sep 5, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For example, Arc<AtomicU64> is a totally reasonable way to handle mutability, here - but this example could have easily used a normal u64 before these changes and still derived Clone, leading to coinciding file handles.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants