10 ms·
That's a common mistake, don't look at channels as queues, one thing is be buffered and other one it's working as a queue, actually buffered channels should be
by yandrypozo 9y ago
That's a common mistake, don't look at channels as queues, one thing is be buffered and other one it's working as a queue, actually buffered channels should be avoided at least you really need a buffer.
- Animats 9y agoHuh?
- thethirdone 9y agoChannels can be made with no buffering at all. In this case trying to send without a receiver is blocking, so the channel is not really acting as a queue anymore. Buffering is only an option to improve performance. Programs should (if they are correct in a sense) be able to work with channels without buffering.
- agentgt 9y ago> Channels can be made with no buffering at all. In this case trying to send without a receiver is blocking, so the channel is not really acting as a queue anymore. It depends on how you define a queue. That is in this case whether there is blocking or not. In Java this distinction is made clear with BlockingQueues and plain Queues. A non buffering blocking queue in Java is a SynchronousQueue or casually known as a hand off queue or rendezvous queue. Unfortunately unlike Go these queues are painfully expensive in Java because Java doesn't have green threads as well I believe the queues use expensive locks (then again locks can be at times more efficient than spinning/sleeping the cpu aka ConcurrentLinkedQueue but in general they are expensive). Going back to the ambiguity of what is a queue it gets even more complicated when talking about distributed queues/streams where you have acknowledgements, prefetching, round robin distribution etc (ie AMQP).