Don't take on too much.

[kelbon]

The very emergence of a modern and understandable alternative to Boost Asio is wonderful. But it seems this library takes on too much.
It should provide a platform-independent interface to sockets, timers, TLS and task queues (IO context), with possibility to implement io_context for my own platform

But don't cross the line of creating a framework. For example, it's important to use awaiters/callbacks everywhere, not coroutines. Boost Asio added its own (awaitable) poorly written coroutines, and that was a mistake. Coroutines can easily be added on top of regular callbacks (even in Boost Asio itself).

I haven't fully examined the entire library yet, but I can already see TCP Server (which I think is redundant) and Capy with its coroutines and framework logic - stop tokens, coroutine scheduling on executors, etc.

It's important to separate the low-level interface from the framework. I'm speaking from experience

[vinniefalco]

Respectfully, I disagree. Users want to write TCP servers, and the implementation provided by Corosio is performant yet difficult to write except by experts (such as the architects of Corosio). This is exactly what a library should provide: something useful which the user would find difficult to write themselves, and which covers a common use-case.

However, I'm open to exploring what other parts of the library you think might be overweight and could use a trim (maybe moved to the examples).

[kelbon]

Honestly, I looked at the server and can say it's abstracted well enough not to not force codestyle like framework.

I also looked at other parts, other libraries by your authors - I think I can appreciate their work, and this almost the best C++ code I've ever seen. It's amazing how similar people come up with ideas when they're striving for the best and are capable of critical evaluation - between the lines of code, I see the same thinking as mine.

The only part of corosio that confuses me is the Capy task. It seems capi coroutines are incompatible with any other coroutines, which is quite typical. On the other hand, unlike asio, corosio doesn't have direct callback interface, so migrating from asio and its coroutines to corosio and its coroutines could be difficult.

So, my question is - how hard it will be to migrate from asio + custom coroutines to corosio + custom coroutines? Something like that https://github.com/kelbon/http2/blob/main/include/http2/asio/awaiters.hpp

P.S.
By the way, about the union on exception_ptr (in capy task) to remove inefficient constructor and destructor calls that aren't inlined... The attention to detail is impressive, but I refused do this in my solution, since everyone except the Windows implementation eventually figured out how to make exception pointers better.

[vinniefalco]

I refused do this in my solution,

Fair but its not just about the performance, I dont want to drag in optional and all the member functions I don't need.

how hard it will be to migrate from asio + custom coroutines to corosio + custom coroutines?

Right now its hard to impossible, and that's because we haven't focused on it. Funny you should ask though, I was just telling @sgerbino that we must make the asio migration story seamless.

Perhaps you could help us?