Glommio is a thread-per-core crate that makes writing highly parallel asynchronous applications in a thread-per-core architecture easier for rustaceans.
DmaFile and OwnedDmaFile can now be cloned instead of just dup. This lets us safely share the FD for DmaFile with background threads without burning more FDs to service the clones. I limited this to just DmaFile because DmaFIle doesn't have a remembered cursor position. This could probably also be replicated for BufferedFile but I'd rather there be a motivating use-case to expose that functionality.
Motivation
The current mechanism for sharing an FD with a background thread requires dup which can limit how many references to a file can exist concurrently in background threads. The use-case is a file server that responds to requests by handing back an FD and a region to respond with
using dup limits how many concurrent requests can be referencing the file at once due to kernel limits on simultaneous open FDs. However, by letting DmaFile be clonable, it lets us send the FD to any thread without risking race conditions about the FD closing while references exist.
This does have a new consequence that close requests may fail if clones exist, but this only impacts those who actually try to clone in the first place, so should have no impact on existing users.
Related issues
646
Additional Notes
I went with a simpler version of just making the relevant types cloneable. That felt cleaner than whatever I was originally going for with BorrowedDmaFile. I also added a polling interface to try to consume the last reference which can be useful if you are implementing a graceful close mechanism on one thread (i.e. you promise to not hand out any more references to the FD & poll closing) with references potentially held open on other threads.
Checklist
[X] I have added unit tests to the code I am submitting
[X] My unit tests cover both failure and success scenarios
[X] If applicable, I have discussed my architecture
What does this PR do?
DmaFile and OwnedDmaFile can now be cloned instead of just
dup. This lets us safely share the FD for DmaFile with background threads without burning more FDs to service the clones. I limited this to just DmaFile because DmaFIle doesn't have a remembered cursor position. This could probably also be replicated for BufferedFile but I'd rather there be a motivating use-case to expose that functionality.Motivation
The current mechanism for sharing an FD with a background thread requires
dupwhich can limit how many references to a file can exist concurrently in background threads. The use-case is a file server that responds to requests by handing back an FD and a region to respond withduplimits how many concurrent requests can be referencing the file at once due to kernel limits on simultaneous open FDs. However, by letting DmaFile be clonable, it lets us send the FD to any thread without risking race conditions about the FD closing while references exist.This does have a new consequence that close requests may fail if clones exist, but this only impacts those who actually try to clone in the first place, so should have no impact on existing users.
Related issues
646
Additional Notes
I went with a simpler version of just making the relevant types cloneable. That felt cleaner than whatever I was originally going for with
BorrowedDmaFile. I also added a polling interface to try to consume the last reference which can be useful if you are implementing a graceful close mechanism on one thread (i.e. you promise to not hand out any more references to the FD & poll closing) with references potentially held open on other threads.Checklist
[X] I have added unit tests to the code I am submitting [X] My unit tests cover both failure and success scenarios [X] If applicable, I have discussed my architecture