The API I came up with for #61 doesn't handle backpressure from failed Write() calls. In NodeJS, the socket is automatically paused and future writes buffered, but only to a limit (called highWaterMark). The socket then emits a drain event once the empty/writes can continue.
There's no such buffering in the C_Networking API, which is a deliberate decision with the goal of simplifying the API, but that means writes can fail and the caller would have to handle it... which of course works against the goal of making the API easy to use.
Maybe the approach used by Node (and Luvit) can be implemented without the giant inheritance hierarchy of streams etc. that I wanted to avoid with the above "basic" implementation. I'll have to look into creating a test scenario (slow receiver/read from socket with timeout) and then consider if the approach can be recreated on top of simple libuv primitives, without too much accidental complexity.
The API I came up with for #61 doesn't handle backpressure from failed
Write()calls. In NodeJS, the socket is automatically paused and future writes buffered, but only to a limit (calledhighWaterMark). The socket then emits adrainevent once the empty/writes can continue.There's no such buffering in the
C_NetworkingAPI, which is a deliberate decision with the goal of simplifying the API, but that means writes can fail and the caller would have to handle it... which of course works against the goal of making the API easy to use.Maybe the approach used by Node (and Luvit) can be implemented without the giant inheritance hierarchy of streams etc. that I wanted to avoid with the above "basic" implementation. I'll have to look into creating a test scenario (slow receiver/read from socket with timeout) and then consider if the approach can be recreated on top of simple libuv primitives, without too much accidental complexity.