goroutine to proceed when encountering many waiting goroutines
reading/writing on a blocked channel? And if so, why are they implemented
that way rather than pure FIFO? I know that select statement behave
pseudorandomly, but to think that blocked channels behave that way too is
making me feel like it's a waste of processing resource.
On Monday, December 29, 2014 3:32:39 AM UTC+7, Kevin Malachowski wrote:
Whoops, I didn't tie that in to specifically talking about sending on
channel. There's definitely no fairness when multiple goroutines try to
read from an empty chan or write to a full one: any goroutine that is
blocked has a chance to be picked once the channel is ready to be sent
to/received from. There is no first come first serve, but since a goroutine
is pseudorandomly picked it ends up being "fair enough" for practical use.
--Whoops, I didn't tie that in to specifically talking about sending on
channel. There's definitely no fairness when multiple goroutines try to
read from an empty chan or write to a full one: any goroutine that is
blocked has a chance to be picked once the channel is ready to be sent
to/received from. There is no first come first serve, but since a goroutine
is pseudorandomly picked it ends up being "fair enough" for practical use.
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
