3 ms·
Exactly. The do / doing / doing-more / ... distinction is most likely just present, because C's threading/event handling model is too primitive. In a language l
by EdSchouten 5y ago
Exactly. The do / doing / doing-more / ... distinction is most likely just present, because C's threading/event handling model is too primitive. In a language like Go you would most likely write this as synchronous code without risking running out of OS threads. In Rust you would use tokio and async / await. No need to come up with all of these imaginary states.
Languages like C also make it notoriously hard to layer/decompose stuff. Why does DNS resolution and proxying need to be part of this state machine? I'm not saying that Go's net/http library is perfect, but at least it got this part right. The http.Client type uses a http.RoundTripper to do all of its networking. Separation of concerns.
- wheybags 5y agoIt seems a little unfair to just jump to the conclusion that the problem is C, with basically no evidence of that. The multitude of "do" states did look confusing to me too, but without reading the code I can't say for sure that it's actually bad, and I definitely can not say why it became bad.
- flohofwoe 5y agoYou can write async/await-style code in C with a simple switch-case state machine. It's not quite as convenient as aync-await support directly in the language, but what's happening underneath is the exact same thing. (meaning: blaming "state machine layout" on the capabilities of the implementation language seems a bit of stretch to me, since async-await language support is essentially just (very high level) syntax sugar for a function that consists of a switch-case block and takes a context pointer as additional argument).