After 6 years, last night I resumed writing about concurrency. Here is how to implement a chan with unlimited buffer in Go: blogtitle.github.io/go-advanced-... - ThreadSky

About ThreadSky

empijei.bsky.social • 81 days ago

After 6 years, last night I resumed writing about concurrency.

Here is how to implement a chan with unlimited buffer in Go:

https://blogtitle.github.io/go-advanced-concurrency-patterns-part-4-unlimited-buffer-channels/

Comments

empijei.bsky.social•79 days ago

@anto.pt thanks for the snipe

anto.pt•79 days ago

can snipe you whenever you want ❤️
i'm happy that this led to you writing a new article on your site 😁

rog.bsky.social•79 days ago

One tiny thought after a moment's glance: your queue can allocate on every item: `queue = queue[1:]` is convenient but discards the capacity at the first element. We should probably have a slice-backed ring buffer in the stdlib actually. container/ring.Buffer seems like a possibility.

empijei.bsky.social•79 days ago

Shouldn't `append` realize that and, once we reach capacity, reallocate a properly sized buffer?

I thought about this but I didn't want to overcomplicate the code for a small performance increase.

empijei.bsky.social•79 days ago

That said, if we want to solve that issue I'd rather use a linked list with potentially a pool for elements. The Ring API is a pain to deal with if you need to grow and it doesn't shrink 😅

rog.bsky.social•78 days ago

I was actually suggesting a new API. *quick nerdsnipe*: something like this, perhaps: https://pkg.go.dev/github.com/rogpeppe/[email protected]/ring
Then your code might look like this: https://gist.github.com/rogpeppe/ce9945c8bd696c59e5d208bbe717648e

rog.bsky.social•78 days ago

and FWIW I suspect the resulting performance increase might not be _that_ negligible: it can result in O(n) allocations for n items passing through the channel.

Posting Rules

Be respectful to others
No spam or self-promotion
Stay on topic
Follow Bluesky's terms of service

Comments

Posting Rules

Reply