- Replace `futures::executor::ThreadPool` by `tokio::runtime::Runtime`. This prepares for using tokio's implementation of `RwLock` with owning lock guards that are `Send`, i.e., can be moved into other threads.
- Handling FUSE_INIT or FUSE_DESTROY requests shouldn't be done concurrently with handling some other request. To enforce this, we require an exclusive reference (`&mut self`) when calling `init()` or `destroy()` functions. Furthermore, those requests (FUSE_INIT, FUSE_DESTROY) shouldn't be reordered with other requests. To enforce this, we lock an `RwLock` from the main thread and move the lock guard into the worker thread. Locking from the main thread ensures that all previously queued requests have already acquired their lock. This way, those requests that require a write-lock (FUSE_INIT, FUSE_DESTROY) cannot be reordered with requests that were enqueued earlier. For similar reasons, they also cannot be reordered with requests that will be enqueued later. --- https://gitlab.com/virtio-fs/virtiofsd/-/merge_requests/85 _______________________________________________ Virtio-fs mailing list [email protected] https://listman.redhat.com/mailman/listinfo/virtio-fs
