You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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 theflock
operation to fail).Under the hood it works by using
tokio::spawn_blocking
and then just using a normalflock
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 astd::fs::File
which gets moved into the thread doing theflock
call. I think in a correct implementation the blocking task thread should get at most aRawFd
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.
The text was updated successfully, but these errors were encountered: