I agree with what you (and the others) say.<p>Regarding green threads and state machines I would however add that while green threads allow to ditch some state machines (e.g. ones that wait until a complete packet was received) you won&#x27;t get rid of all of them, e.g. you will still need state machines for lots of protocol implementations. E.g. if you are implementing the websocket protocol or HTTP&#x2F;2, you have some interaction between incoming data, data that must be sent out and requests from the [library] user. The state of the connection depends on all of these, so you need some kind of connection state machine which would run most likely in it&#x27;s own green thread (in addition to a sending thread and a receiving thread and a user thread). And now you have to implement clean synchronization between all of those threads. The lack of necessary synchronization (and the ability to observe a huge amount of state at once without danger) can make the implementation a little bit more easy in my experience. But here I also have to agree with strmpnk that a good design is necessary for both approaches, and accessing lots of shared mutable data in multiple callbacks is probably also not the cleanest approach.