A question for those familiar with the runtime internals of channel close
and channel receive:
In trying to get channels to match the superior performance of sync.Cond,
I have come across one potentially viable strategy: using close to
interrupt an otherwise
blocked send. For example:
ch := make(chan int)
go func() {
time.Sleep(time.Second)
close(ch)
}()
recevieAndCatch := func() {
defer func() {
recover()
}()
for i := range a_slice_of_stuff_to_send {
ch <- a_slice_of_stuff_to_send[i]
}
}
receiveAndCatch()
// we get here after ~sec
Similar to how the standard library json package handles deep errors by
using panic/recover as an exception mechanism,
e.g.
https://github.com/golang/go/blob/master/src/encoding/json/decode.go#L171
this strategy depends upon catching the resulting panic with recover().
However, since the recover can be hoisted high above the tight inner
loop, this strategy ends up being the only one I've found that actually
out-performs sync.Cond.
So we have performance, but how about correctness? So finally, to my
question:
Will closing a channel in the middle of a send introduce the possibility of
data corruption? The language spec guarantees a panic, and that panics
can be recovered, but would a *reader* of ch above ever see incorrect data?
--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
