|
| 1 | +corosio key insight: |
| 2 | +coroutine frame allocation cannot be avoided for i/o patterns |
| 3 | +the allocation we cannot avoid, pays for the type-erasure we need |
| 4 | +the lifetime of parameters passed to your coroutine extends until you finish |
| 5 | +type-erasure at the coroutine boundary is thus essentially free (you already paid for the frame) |
| 6 | +7:15 |
| 7 | +Asio cannot do this, because it was not written coroutines-first |
| 8 | +7:16 |
| 9 | +so in asio you end up with stupid shit like any_buffers |
| 10 | +7:16 |
| 11 | +in corosio, your buffer sequence stays in its natural type until the end where it is efficiently dissected into a platform struct |
| 12 | +7:16 |
| 13 | +in asio, you use any_executor and that gets passed through all the layers. if your executor is big, you pay |
| 14 | +7:16 |
| 15 | +in corosio, your executor no matter how complex (sizeof can be 500 bytes), it only costs 2 pointers |
| 16 | +7:17 |
| 17 | +in asio your completion handler grows with each layer of abstraction, struct within struct within struct. the compiler sees through the whole thing, yes, but those memmove of the ever-larger structs add up. (edited) |
| 18 | +7:17 |
| 19 | +in corosio, the "completion handler" is only ever one pointer (std::coroutine_handler) and each layer of abstraction adds just one more pointer |
| 20 | +7:18 |
| 21 | +5 layers of asio handlers could be 500 bytes, in corosio it is 40 bytes |
| 22 | +7:18 |
| 23 | +furthermore in asio, the i/o operation is templated on all that bullshit, creating NxM combinatorial explosion of both size and code |
| 24 | +7:19 |
| 25 | +in corosio, i/o objects operation sizes are known at compile time, not visible outside the TU, and preallocated. no need for a recycling ops allocator |
| 26 | +7:19 |
| 27 | +now all I need to do is talk about corosio's "negative overhead" |
| 28 | +pdimov |
| 29 | + 7:40 PM |
| 30 | +JUCB |
| 31 | +Vinnie |
| 32 | + 7:48 PM |
| 33 | +JUCB. |
| 34 | +7:49 |
| 35 | +complex refactoring, handled |
| 36 | +http does not depend on boost.buffers, fix cmake and jamfiles, change all includes to corresponding capy buffers includes, rename symbols if needed, compile and fix until successful |
| 37 | +7:49 |
| 38 | +merging buffers to capy was the right move |
| 39 | +7:49 |
| 40 | +Oh, here's the cool thing |
| 41 | +7:50 |
| 42 | +when I finish this, it will show how the C++ committee has a path to standardizing the coroutines-first execution model optimized for networking (capy) and they can leave the networking piece to third parties, sidestepping all the bickering and gnashing of design teeth |
| 43 | +7:50 |
| 44 | +with this, there's no need to standardize corosio |
| 45 | +7:50 |
| 46 | +you can write for capy and then just link in your favorite lib |
| 47 | +7:51 |
| 48 | +ABI-stable by design |
0 commit comments