Hi, Louki Sumirniy This is not really a response to your problem in particular, so it may totally miss your target. It's been a while since I did anything in this group. However, it's a response to the use of buffered channels. It's a coincidence that I react to your posting (and not the probably hundreds of others over the years where this comment may have been relevant). But I decided this morning to actually look into one of the group update mails, and there you were!
In a transcript from [1] Rob Pike says that “Now for those experts in the room who know about buffered channels in Go – which exist – you can create a channel with a buffer. And buffered channels have the property that they don’t synchronise when you send, because you can just drop a value in the buffer and keep going. So they have different properties. And they’re kind of subtle. They’re very useful for certain problems, but you don’t need them. And we’re not going to use them at all in our examples today, because I don’t want to complicate life by explaining them.” I don't know if that statement is still valid, and I would not know whether your example is indeed one of the "certain problems" where you have got the correct usage. In that case, my comments below would be of less value in this concrete situation. Also, whether there is a more generic library in Go now that may help getting rid of buffered channels. Maybe even an output into a zero-buffered channel in a select with a timeout will do. If you fill up a channel with data you would often need some state to know about what is in the channel. If it's a safety critical implementation you may not want to just drop the data into the channel and forget. If you need to restart the comms in some way you would need to flush the channel, without easily knowing what you are flushing. The message "fire in 1 second if not cancelled" comes through but you would not know that the "cancel!" message was what you had to flush in the channel. In any case, a full channel would be blocking anyhow - so you would have to take care of that. Or alternatively _know_ that the consumer always stays ahead of the buffered channel, which may be hard to know. I guess there are several (more complex?) concurrency patterns available that may be used instead of the (simple?) buffered channel: All of the patterns below would use synchronised rendezvous with zero-buffered channels that would let a server goroutine (task, process) never have to block to get rid of its data. After all, that's why one would use a buffered channel; so that one would not need to block. All of the below patterns move data, but I guess there may be patterns for moving access as well (like mobile channels). All would also be deadlock free. The Overflow Buffer pattern uses a composite goroutine consisting of two inner goroutines. One Input that always accepts data and one Output that blocks to output, and in between there is a channel with Data one direction that never blocks and a channel with Data-sent back. If the Input has not got the Data-sent back then there is an overflow that may be handled by user code. See [2], figure 3. Then there are the Knock-Come pattern [3] and a pattern like the XCHAN [4]. In the latter's appendix a Go solution is discussed. - - - [1] Rob Pike: "Go concurrency patterns": https://www.youtube.com/watch?v=f6kdp27TYZs&sns=em at Google I/O 2012. Discussed in [5] Disclaimer: there are no ads, no gifts, no incoming anything with my blog notes, just fun and expenses: [2] http://www.teigfam.net/oyvind/pub/pub_details.html#NoBlocking - See Figure 3 [3] https://oyvteig.blogspot.com/2009/03/009-knock-come-deadlock-free-pattern.html Knock-come [4] http://www.teigfam.net/oyvind/pub/pub_details.html#XCHAN - XCHANs: Notes on a New Channel Type [5] http://www.teigfam.net/oyvind/home/technology/072-pike-sutter-concurrency-vs-concurrency/ -- 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.
