3 ms·

Let me state explicitly, in either case you should be dealing with full channel cases. I'd probably make a lot more use of empty channels if go had more sophis

Let me state explicitly, in either case you should be dealing with full channel cases. I'd probably make a lot more use of empty channels if go had more sophisticated primitives around that. If I could say, publish to this channel until a timeout without all the overhead that is currently required. As it stands (on my workloads), with unbuffered channels its hard to figure out if you have encountered a localized short term full channel or you've achieved some more degenerate case where you should be taking drastic load shedding action. Buffered channels make rough approximations of this very easy. Under normal operating modes this shouldn't be full. If it is sound the klaxon and begin load shedding. And for most things that aren't pipelines, I simply don't think channels are very appropriate.

jnordwick 9y ago
What?? Go channels don't have timeouts? I had to read about this and I'm a little dumbfounded. Why wouldnt Go support timeouts for channels? The extra complexity seems huge especially if you wanted a timeout that was different than the library based hack -- for example if you wanted a timeout since last write. I don't understand what the Go devs are protecting people from.
- packetslave 9y ago
  It’s trivial to implement a channel read with timeout using select and time.After(). The first N google results for “golang channel timeout” show exactly that.
  - jnordwick 9y ago
    It is still overly complex and only handles one specific timeout case. A timeout per connection? That can be a lot of extra goroutines for such a simple thing. Or if you want a 30 second timeout since the last read? Way more complex. Go's channels seem more than a little under developed.
  - kasey_junk 9y ago
    It’s worth noting that eliminates the range option which means you need to handle all the edge cases around closed/nil channels by hand. On the publish side in most production cases you don’t want to use time.after as it leaks. So you’ll use either a context or a timer. All told it’s a fair bit of boilerplate to get right everytime (which you can’t genericize) which is why I tend to use buffered channels that are sized such that being full is a degenerate case.

jnordwick 9y ago

What?? Go channels don't have timeouts? I had to read about this and I'm a little dumbfounded. Why wouldnt Go support timeouts for channels? The extra complexity seems huge especially if you wanted a timeout that was different than the library based hack -- for example if you wanted a timeout since last write. I don't understand what the Go devs are protecting people from.

packetslave 9y ago
It’s trivial to implement a channel read with timeout using select and time.After(). The first N google results for “golang channel timeout” show exactly that.
- jnordwick 9y ago
  It is still overly complex and only handles one specific timeout case. A timeout per connection? That can be a lot of extra goroutines for such a simple thing. Or if you want a 30 second timeout since the last read? Way more complex. Go's channels seem more than a little under developed.
- kasey_junk 9y ago
  It’s worth noting that eliminates the range option which means you need to handle all the edge cases around closed/nil channels by hand. On the publish side in most production cases you don’t want to use time.after as it leaks. So you’ll use either a context or a timer. All told it’s a fair bit of boilerplate to get right everytime (which you can’t genericize) which is why I tend to use buffered channels that are sized such that being full is a degenerate case.