Restioson

Ah, that is true!

This is a pure refactor, right?

Cool :) In that case, feel free to merge when ready

Currently, there are no benchmarks which are asynchronous, as we're not really sure how async benches should be measured. Do you have any suggestions to do so? The other option...

How should the performance of the tasks be measured? We could `block_on` them and throw them in a criterion `b.iter` but this could also just be measuring general futures overhead

There has been some talk on the T-libs Zulip about this, so it's definitely a goal! Currently we are fixing some bugs and trying to optimize so that we don't...

Yea. I think it would probably need to be source copied into std because of this?

So the idea then would be that std would use the core and wrap it (in house) with synchronicity primitives to fit in the mpsc api?

I wonder how this interacts with #39 for select macros in loops.

> Is this possible without some kind of request/reply correlation IDs? my fear is that you would transmit a message, then switch to being a receiver, but receive a response...