Drain channel on demand without busy looping?

[cpu...@gmail.com]

I have the requirement of being able to drain a channel, i.e. make sure that downstream processes all data currently being sent. One possible pattern is something like

for{

select{

case <-q.data:

default:

}

}

where the default branch could indicate that channel has been drained. My concern is, that this would create a busy loop on the default branch even when not trying to drain the channel.

I could use an atomic for checking if work should be done in default (i.e. signal channel has been drained).

Would that still busy-loop? Are there better patterns?

Cheers,

Andi

[Jan Mercl]

On Sun, Feb 5, 2023 at 5:12 PM cpu...@gmail.com <cpu...@gmail.com> wrote:

> Would that still busy-loop? Are there better patterns?

for range q.data {}

iff the sending side properly closes the channel.

[Jason E. Aten]

I have the requirement of make sure that downstream processes all data currently being sent. 

I usually have the client submit a Request struct the includes a new Done channel. When the downstream goroutine

finishes processing a given Request r, they close the r.Done channel. The client can wait or select on the r.Done channel to

know when processing is finished.

 

[Andreas Götz]

Thanks Jason,

that is absolutely beautiful. Ranging over channel wont work when the channel remains open (my case), but the "callback" pattern is really nice.

Much appreciated,

Andi