coio is not build in cargo.io migrate to tokyo the tls module
kurojishi opened this issue · comments
to unlock #32 coio has to go
it's used in the TLS module as a scheduler and to control tcplistener and stream.
The package doesn't seem to have been touched for at least an year:
https://github.com/zonyitoo/coio-rs
I'm gonna start working on this
It would be very helpful thanks !
Hmm.. I'm starting to think, if it's worth keeping the coroutines version of TLS and TCP input. The splitters aren't implementing any futures, so the TCP/TLS input would basically spawn a single coroutine for every incoming connection and that's all.
https://tokio.rs/docs/io/reading_writing_data/
From what I understand the current splitter implementation does not support async reading from streams and the tokio TcpStreams are working asynchronous.
@jedisct1 am I missing something here?
Splitters are very fast, I don't expect that to be a bottleneck. And the output eventually gets pushed to a queue.
But spawning a new thread for each TCP connection has a cost. I don't remember the details, but that used to be a major issue when the initial version of flowgger was deployed at OVH (where most clients didn't use long-lived sessions), and coroutines immediately solved it.
Migrating to tokio or async-std is a good idea, but it wouldn't be surprising to see a performance regression over coio. If this is the case, may can be a drop-in replacement for coio.
To clarify, I named dropped tokyo in there without doing an excessive amount of research while opening this one, because that's the one i knew. So feel free to drift out of Tokyo to something more performant
Resolved by PR #51