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

Cancellation and file descriptors #22

Open
withoutboats opened this issue May 28, 2020 · 4 comments
Open

Cancellation and file descriptors #22

withoutboats opened this issue May 28, 2020 · 4 comments

Comments

@withoutboats
Copy link
Collaborator

User sintrowel on Reddit comments:

I may very easily be not considering something. However, with the existing Ringbahn interfaces I think its possible for an operation to get queued up for a particular file descriptor without being immediately submitted. Then, prior to being submitted, the future that submitted the operation is dropped, causing the file descriptor to be closed. However, the operation is still queued up, and, once it is actually submitted, will either act against an invalid file descriptor or end up acting on some other unrelated file. Is this possible, or is there a mechanism to prevent this that I did not see in the code?

I need to think about this more. With Event you're taking a raw FD, and its sort of your responsibility. But Ring should handle closing itself properly.

The problem is managing the lifecycle, because dropping the future representing a read/write is not the same as closing the FD. So you could cancel -> do more IO -> etc or you could cancel -> close. Ring probably needs to be more aware of the state of past IO interest that hasn't completed in some way.

@withoutboats
Copy link
Collaborator Author

Probably the way cancellation on Ring should work is that when you try to issue a new event on the FD Ring manages, if another event is underway, Ring issues a cancellation linked before the new event, so the ongoing event will be cancelled, then the new event will proceed, no matter what the two events are.

And the Event API will want to provide a manually implement this behavior as well.

@VShell
Copy link

VShell commented Jun 5, 2020

@withoutboats That idea doesn't work for me - I'd like multiple independent operations working against the same fd (that is, multiple Rings operating against a single fd, along with Events and so on). io_uring's opcodes do not seek the file pointer internally afaict, so this should be easy from that perspective.

For my use case, I'd like to see Ring be able to take an Rc or Arc to an AsRawFd object, then drop it when the Ring is dropped + all in-flight requests in that Ring referencing it are completed. I have implemented a similar thing for a custom Event.

@withoutboats
Copy link
Collaborator Author

@VShell probably the ring state machine should be exposed as a low level interface you could use to build a shared ring construct.

@withoutboats
Copy link
Collaborator Author

Hopefully avoided by #47, but I never got feedback on axboe/liburing#147

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 a pull request may close this issue.

2 participants