On Friday, December 29, 2017 at 3:33:15 PM UTC-6, dc0d wrote: > > The statement being made here: a receive only channel, as a return value > of a function, in an API, is not bad. > > Reasoning: > > > - can not be closed > - can not be set to nil > - it's more clear than callbacks > - if signaling is the desired behavior, callbacks for sure are the > wrong choice > - internals of the API might be affected by unknown behavior of > callbacks > - lets the consumer decides how many goroutines is needed to handle it > > The last item especially is important since creating one goroutine per > result item might not be the most efficient way. And if the API internals > have no idea how to schedule the callbacks (panics aside) to make most of > the machine resource (IO/CPU). > > I would appreciate any help with the proposed (problem and) solution > (reasoning). >
Either is fine and the advantages of one over the other can be subtle and context dependent. I typically think that for the utmost flexibility and performance at scale, I prefer callbacks, so as not to require the client use additional goroutines if they do not wish to. The client can then send on their own channel, should they prefer. It leaves the choice to them. But it may depend on how adversarial you expect clients to be. The price for more guarantees is typically lower performance. Every channel operations requires synchronization under the covers, with all the cache coherency protocol slowness that implies, and at scale, that can be a drawback. -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
