> Neither. Return a blocking iterator, something like
>
> type Iterator struct {
> // Next blocks until a new message is available or the stream ends and
> returns if a new message is available.
> Next() bool
> // Message returns the current message. Must only be called after Next
On Thu, Sep 16, 2021 at 11:17 PM yba...@gmail.com wrote:
> - Design in a non-blocking tcp way (that is let the user use
> select()/poll()/epoll() sycall).
> - Or design it with blocking tcp io inside go routines, which would return
> 2 channels (read and write). Then let the user do a
The advantage of Go is to be able to use millions of blocking Go routines.
Synchronous programming is much easier than async - especially for streaming
protocols.
> On Sep 16, 2021, at 4:17 PM, yba...@gmail.com wrote:
>
> Hello everyone,
>
> I am trying to design a new library to
Hello everyone,
I am trying to design a new library to encode/decode MQTT messages. I began
the work, and now I must decide how to design the TCP processing of my
library, and I am facing two choices:
- Design in a non-blocking tcp way (that is let the user use
select()/poll()/epoll() sycall).
