I will argue if it is ok to drop the oldest then it is ok to drop all but the 
latest. You need more metrics on volume and latency requirements to know which 
is the proper approach. 

> On Nov 15, 2020, at 8:01 PM, Kurtis Rader <kra...@skepticism.us> wrote:
> 
> 
>> On Sun, Nov 15, 2020 at 3:45 PM 陶青云 <qingyu...@gmail.com> wrote:
> 
>> 
>> 在2020年11月15日星期日 UTC+8 下午12:19:07<Kurtis Rader> 写道:
>>>> On Sat, Nov 14, 2020 at 7:54 PM Robert Engels <ren...@ix.netcom.com> wrote:
>>>> I don’t think a ring buffer works. At least in a traditional ring buffer 
>>>> the producer cannot pass the consumer - if the buffer is full the producer 
>>>> blocks or drops. Trying to ensure the consumer always reads the most 
>>>> recent available item is better (and more simply) served with a shared 
>>>> hand off queue.
>>> 
>>> It is trivial to create a ring buffer type that drops the oldest queued 
>>> item when appending a new item if the ring is full. Which would seem to be 
>>> the behavior the O.P. wants. The important question in this scenario is 
>>> whether such an object must be useful in a `select` statement. If not the 
>>> implementation is borderline trivial.
>>> 
>> The ring buffer should work, but it seems to need the consumer to test and 
>> sleep when the ring is empty, which is not as efficient as a channel.
> 
> If I was doing this in C I would use a counting semaphore. In Go create a 
> channel of the empty interface. Whenever the producer adds an entry to the 
> ring, and the ring isn't already full, it sends `nil` on the channel. When 
> the consumers/workers receive a `nil` token from the channel they know there 
> is a new entry in the ring buffer to be processed. Voila! Your ring buffer 
> now plays nicely with `select. Note that you still need a spinlock to protect 
> modifications of the ring buffer by the producer(s) and consumers.
> 
> -- 
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
> -- 
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/CABx2%3DD9ct-BBJskMmXn-88E6HtJEciEyFpOOYpi9yAFWAtpLCA%40mail.gmail.com.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/B760C850-AB15-4C32-903F-BA38B52C9EC5%40ix.netcom.com.

Reply via email to