tokio-uring
tokio-uring copied to clipboard
tokio-rs
Dead or dying?
I hate to ask this, but traffic here appears to have all but died up. I don't know the reason for this, if the current maintainers (I don't even know who you all are) have lost interest / business need / or just have no time, but I'd like to volunteer to take up some tasks, if that helps reinvigorate this project?
tokio_uring isn't dead, but it does have a bus factor problem. I've been very busy for the past year, that has definitely halted a lot of work on this repo. I'm looking to become more active again with this, and want to push through some PRs soon that I have which are relevant here, however I have come to recognize that we need more maintainers for this.
@ollie-etl, you've been a frequent contributor for a while. Would you be interested in joining as a maintainer?
@Noah-Kennedy Yes - i'm also busy, but am quite invested in this crate at this point, and would much rather PRs progressed rather than stalled or died.
@Noah-Kennedy when you find the time to add me, would you add me as both @ollie-etl and @oliverbunting. I have a work and personal profile
Hello! I've recently come across this repository and I'm curious to know if it's still actively maintained.
I have some experience with io_uring, so I would like to help if this project needs contributions. (If so, could you suggest some tasks to get started?)
@xiaoyang-sde I've been recently added as a maintainer, and I am still an active user of the crate.
In terms of direction, I guess everyone has different priorities however, in my my view, I see the following themes for improvemnt
More control over ring submission
Currently, Ops are submitted on creation. I think there is some consensus that perhaps we want to split creation and submission. Not least because this is probably a pre-requisite for chaining ops
Improved cancellation
Some ops don't matter if you just drop and forget them. Soem do though. If you call rx on the ring, you may wish to recover the buffer back. This won't happen until a packet is recieved currently
Improved ergonomics
This is a bit of an op exlosion happening, for many things which are basically variantions. This is probably indicative we need more of a builder style Api for each Op
@xiaoyang-sde I've been recently added as a maintainer, and I am still an active user of the crate.
In terms of direction, I guess everyone has different priorities however, in my my view, I see the following themes for improvemnt
More control over ring submission
Currently, Ops are submitted on creation. I think there is some consensus that perhaps we want to split creation and submission. Not least because this is probably a pre-requisite for chaining ops
Improved cancellation
Some ops don't matter if you just drop and forget them. Soem do though. If you call rx on the ring, you may wish to recover the buffer back. This won't happen until a packet is recieved currently
Improved ergonomics
This is a bit of an op exlosion happening, for many things which are basically variantions. This is probably indicative we need more of a builder style Api for each Op
Thanks for the quick response! I’m still learning the source code of related projects and will see what I can help after the holiday season.
I am also happy to help if needed. Feel mark me as a reviewer for pull requests, for example.
