For what it's worth, I would argue that the 1-buffered channel pattern in
Go *is* “basic concurrent programming”. 1-buffered channels are used as
basic building blocks throughout the standard library — consider
time.Ticker or signal.Notify — and for good reason. A 1-buffered channel is
a very
On Tue, Apr 13, 2021 at 3:00 PM Roman Leventov
wrote:
> Jesper, a single channel works if I provision it with big enough capacity
> (1000), but this feels like an antipattern which can break.
>
Yes.
On the flip side though, unbounded channels are also dangerous if the
producer(s) outpaces
Have the channel hold a slice of objects and process them as a batch. Batch in
- batch out.
Typically unless your traffic is bursty - a faster producer than consumer will
either cause blocking, data loss (drops) or failure (oom).
> On Apr 13, 2021, at 8:00 AM, Roman Leventov wrote:
>
>
>
Jesper, a single channel works if I provision it with big enough capacity
(1000), but this feels like an antipattern which can break. Still, this is
probably the most practical option.
Brian, thanks for sharing, yes this pattern solves my problem much simpler
than I have. Although it doesn't feel
Bryan Mill's presentation on go concurrency patterns is well worth watching
all the way through:
https://www.youtube.com/watch?v=5zXAHh5tJqQ
There are lots of code snippets which are directly relevant to what you're
trying to do, e.g. from 20:48 is a queue with Get, and 21:59 a queue with
On Tue, Apr 13, 2021 at 12:53 PM Roman Leventov
wrote:
> type Frame struct{}
>
> type Connection struct {
> sem*semaphore.Weighted // from http://golang.org/x/sync/semaphore
> mu sync.Mutex
> frames []*Frame
> }
>
>
My immediate hunch when reading your code was:
type Connection struct {
I'm trying to implement a simple Connection type:
type Connection {
// Puts a batch of frames into a queue which can later be read.
// This method is called only from a single goroutine.
PutFrames(frames []*Frame)
// Returns a frame from the queue if present, with timeout.
// This
