4 ms·

FWIW, it's not obvious that the one-thread one-connection blocking I/O design is terrible. Any time you're using a 'thread' idiom, even if they are green, some

by blasdel 18y ago

FWIW, it's not obvious that the one-thread one-connection blocking I/O design is terrible. Any time you're using a 'thread' idiom, even if they are green, something has to be maintaining their individual execution state (stack frames, thread-local address space, etc.). I like to think of it as being analagous to unoptimized tail-recursion, with a purely event-driven callback model being like tail-call optimization. Thanks for explaining Windows' overlapped I/O, it's way better than I thought it was from reading the documentation. I didn't realize that it does all the thread-pooling stuff all by itself -- I guess it makes the most sense not to fight it, and just accept the free utilization (even if it does give a slight latency hit).

barrkel 18y ago
No - not tail call - event driven callback model I/O is continuation-passing style (CPS). The two models are equivalent. Code written in the thread idiom can, in principle, be mechanically transformed into CPS and thereby use the event-driven callback model. In the event callback style, the state that would otherwise be on the stack is held in the callback closure. In the .NET space, F# does this transformation automatically with what it calls asynchronous workflows (http://blogs.msdn.com/dsyme/archive/2007/10/11/introducing-f-asynchronous-workflows.aspx http://blogs.msdn.com/dsyme/archive/2007/10/11/introducing-f...). It uses the 'let!' assignment as a dividing point between the call to the asynchronous method and converting the remainder of the method body into a continuation that gets passed to the asynchronous call.