Open trickster opened 2 years ago
There is an example to use hyper with monoio. But hyper with custom runtime has some overhead(and the biggest problem is there may be some soundness issues since the diffrence of io interface: readiness based and completion based io).
So here the short answer is: Do not do that.
Currently we are developing a pure async http framework(link) from scrach. Now the h1 protocol is nearly finished, but it can not be used in production yet.
@ihciah thanks for reply. I see tokio-uring
advertising they are compatible with hyper
and tonic
though. Not really sure if they are compatible with total tokio stack (tokio
, tower
, hyper
, axum
)
I am also investigating this library that is the best runtime agnostic http library I have ever come across, no runtime dependencies for trillium (but there are adapters for smol, async-std and tokio). This is not the fastest library out there (yet) tho, and also not very popular, but probably the easiest to use.
Tokio is compatiable with hyper and tonic but tokio-uring is not. The tokio's way is to support uring based on epoll, anything epoll supports will work(and maybe uring is or is not used). Here our way is to hide the driver and allow users write only one set of code. The problem I mentioned(readiness based and completion based io) is not related to implemention detail. So what here we faces, other frameworks must face. For HTTP framework, they can hardly to be runtime(at least io) independent. Hyper and axum depends on tokio::io, and trillium depends on async-io. These two io interfaces are all readiness based(normally they sense the io interests ready and do io syscall afterwards).
The library I linked only uses futures_lite::io
which is runtime agnostic. But yes, there is Send + Sync
everywhere like here which is not needed at all
Yes, all async-std related crates(including futures_lite, smol and async-io) use futures-io. It is readiness based.
Send and Sync is another thing. I think it is not the most improtant problem here.
Readiness based io can be canceled anytime, just not do syscall. But completion based io cannot(like io-uring, you submitted the fd and buffer pointer, you must wait for it. Otherwise if the buffer is dropped, the kernel may write to a wrong position). To solve the problem, tokio-uring and we choose to take the buffer ownership. So you can see there two styles of io interface is different and cannot be totally compatiable. It is impossible to use io_uring with readiness style io interface.
Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Create an example using
axum::Server
with custom runtime and method routers. Axum is a very good abstraction for servers. It has routers, extractors etc, which are convenient. However, when using it withmonoio
it is not trivial because of a bunch of reasons.I tried using
make_service_fn
from hyper, but it takesAddrStream
instead ofTcpStream
, unfortunatelyAddrStream
has no public constructor.Describe the solution you'd like A clear and concise description of what you want to happen.
In
hyper_server
example,we should be able to get
basically axum handlers.
Additional context Add any other context or screenshots about the feature request here.
If we can't manage to get this done, we can talk to hyper/axum maintainers to allow for some abstractions for different kinds of executors.