To clarify, you might never process a low item if a high is always available - 
but I believe that is what the OP is requesting.

It is also fairly trivial to add fairness to this ti always process a low if 
available every N cycles.

> On Apr 29, 2021, at 9:31 AM, robert engels <reng...@ix.netcom.com> wrote:
> 
> It is not.
> 
> Because the low items will be read if there are no highs available. If the 
> low isn’t read, the producer on the low will block.
> 
> Or you run out of memory if you cannot process the events fast enough - which 
> is also easily handled by bounding the queue - but then you may need to drop 
> items.
> 
> There are no free lunches.
> 
> But no deadlock.
> 
> 
> 
>> On Apr 29, 2021, at 9:26 AM, Ian Davis <m...@iandavis.com 
>> <mailto:m...@iandavis.com>> wrote:
>> 
>> On Thu, 29 Apr 2021, at 3:09 PM, robert engels wrote:
>>> I will give you the pseudo code:
>>> 
>>> { // step #1 do select on both
>>>    select high
>>>    select low
>>> }
>>> 
>>> if high read:
>>>    return high
>>> else:
>>>    // we read a low so do a high poll
>>>    {
>>>        select high:
>>>        default:
>>>    }
>>> 
>>>  if high read:
>>>       enqueue low and return high
>>>  else:
>>>       if queue empty:
>>>          return low
>>>       else:
>>>            use queue and enqueue low from step #1 // FIFO order on low 
>>> reads 
>>> 
>>> The above code will always return high values over low values (if high 
>>> available), and return low values in order of events
>> 
>> This seems likely deadlock if the low channel is being filled continually by 
>> another goroutine. In addition I usually aim to give ownership of the 
>> channel to the writer so it can close cleanly, but mixing reads and writes 
>> in a single function greatly complicates that.
>> 
>> Ian
>> 
>> -- 
>> 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 
>> <mailto:golang-nuts+unsubscr...@googlegroups.com>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/f26ee7f2-a518-433f-89d4-d55aa0a9b07d%40www.fastmail.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/f26ee7f2-a518-433f-89d4-d55aa0a9b07d%40www.fastmail.com?utm_medium=email&utm_source=footer>.
> 
> 
> -- 
> 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 
> <mailto:golang-nuts+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/00218548-6E27-4E16-A75F-88B6E30195E5%40ix.netcom.com
>  
> <https://groups.google.com/d/msgid/golang-nuts/00218548-6E27-4E16-A75F-88B6E30195E5%40ix.netcom.com?utm_medium=email&utm_source=footer>.

-- 
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/10A8C321-E56E-43D2-8E00-C95AF52AD1E8%40ix.netcom.com.

Reply via email to