coio is not build in cargo.io migrate to tokyo the tls module

[kurojishi]

to unlock https://github.com/awslabs/flowgger/issues/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

[Trojan295]

I'm gonna start working on this

[vche]

It would be very helpful thanks !

[Trojan295]

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?

[jedisct1]

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.

[kurojishi]

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

[kurojishi]

Resolved by PR #51