I've added https://go-review.googlesource.com/c/go/+/412237 to try to make
this obvious to more people.
On Sun, Jun 12, 2022 at 2:47 AM Brian Candler wrote:
> And just as an aside, I think you would be interested in the talk
> "Rethinking Classical Concurrency Patterns" by Bryan C. Mills
> ht
And just as an aside, I think you would be interested in the talk
"Rethinking Classical Concurrency Patterns" by Bryan C. Mills
https://www.youtube.com/watch?v=5zXAHh5tJqQ
On Sunday, 12 June 2022 at 05:06:47 UTC+1 ke...@burke.dev wrote:
> That's a very clear explanation, it's obvious what the pr
That's a very clear explanation, it's obvious what the problem is now.
Thank you!
On Saturday, June 11, 2022 at 9:36:59 AM UTC-7 se...@liao.dev wrote:
> sync.Cond does not affect goroutine scheduling priority, and Signal only
> makes the waiting goroutine available to be scheduled, but not forc
sync.Cond does not affect goroutine scheduling priority, and Signal only
makes the waiting goroutine available to be scheduled, but not force it to
be.
After a Signal() (and Unlock()), every other waiting worker and the flusher
then contends (fairly) for the lock.
What you want appears a better fit
Hi,
Recently I inherited some code in production that was hitting an error case
that I didn't think should be possible to hit. I reduced it down to this
test case. To be clear, there are several different ways to improve the
code here, but I'd like to understand why it's behaving the way it does
