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

I think this crate leaks threads + fds when you drop futures #3

Open
bjackman opened this issue Dec 8, 2024 · 0 comments
Open

I think this crate leaks threads + fds when you drop futures #3

bjackman opened this issue Dec 8, 2024 · 0 comments

Comments

@bjackman
Copy link

bjackman commented Dec 8, 2024

I guess this is not actively maintained but just dropping a note in case it's of use to anyone...

I haven't actually tested this so if this is a concern for you it's worth verifying for yourself. But, I think this create will leak threads and file descriptors if you drop the futures returned by lock_exclusive etc (unless the file successfully get locked, or something causes the flock operation to fail).

Under the hood it works by using tokio::spawn_blocking and then just using a normal flock call in the thread. But as noted in the Tokio docs, if you use that API you need to think about cancellation.

I guess the way to cancel a flock call is to close the file descriptor. But this crate doesn't seem to do that - the fd is in a std::fs::File which gets moved into the thread doing the flock call. I think in a correct implementation the blocking task thread should get at most a RawFd which can be closed from the other thread if the future gets dropped.

Depending on usecase, I think this leakage is very likely to be harmless. But if you expect to often contend for files that are locked for a long time it could be more of a real issue.

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

No branches or pull requests

1 participant