You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is there a way for an event handler to detect when at least N bytes of input are available on a socket?
I am implementing a protocol where I know how big each message will be and it seems neat to allow partial messages to be buffered in cl-async and only read when completely available. Just now I am not seeing a way to e.g. check how many bytes of input are available on a stream.
(I am also confused by the examples of reading from streams in socket callbacks. Are those blocking reads that can hang the event loop? Can you use the non-auto-draining stream interface when you want to strictly avoid blocking operations?)
The text was updated successfully, but these errors were encountered:
I saw a crossroads. On the one hand I can keep my code simple and have cl-async accumulate data in the input stream and always give me complete messages. That seems to require exposing more information about the buffer inside the stream object. On the other hand I can do the buffering myself. That seems potentially simpler in operational terms because then I operate on the data immediately when it is delivered by the libuv callback without intermediate buffering in a cl-async stream object.
I am trying the second route at the moment. Instead of reading whole known-size messages from cl-async streams I am just running a state machine on each byte of input.
Is there a way for an event handler to detect when at least N bytes of input are available on a socket?
I am implementing a protocol where I know how big each message will be and it seems neat to allow partial messages to be buffered in cl-async and only read when completely available. Just now I am not seeing a way to e.g. check how many bytes of input are available on a stream.
(I am also confused by the examples of reading from streams in socket callbacks. Are those blocking reads that can hang the event loop? Can you use the non-auto-draining stream interface when you want to strictly avoid blocking operations?)
The text was updated successfully, but these errors were encountered: