Why are we duplicating logic fromSendLoop here? Since this method doesn't attempt to send, it's quite pointless unless the signaling is happening from a runningSendLoop anyway.

Edit: Ah, nevermind, just realized this is only here to handle the user provided context.

I think this could be greatly simplified:

func (l*LogSender)WaitUntilEmpty(ctx context.Context)error {select {case<-ctx.Done():returnctx.Err()case<-l.allSent:returnnil}}

The problem with anallSent channel is how to arrange when it should read. Closing the channel won't work, because you can't "unclose" it if more data gets queued.

Writing to the channel won't work if there are more than one caller to WaitUntilEmpty.

True, it would work better/simpler if the send loop was channel-based as well. In that case, one approach could be this:

func (l*LogSender)WaitUntilEmpty(ctx context.Context)error {wait:=make(chanstruct{})l.waitUntilEmpty<-waitselect {case<-ctx.Done():returnctx.Err()case<-wait:returnnil}}// SendLoopvarwaiters []chanstruct{}for {select {case<-tick:case<-l.waitUntilEmpty:waiters=append(waiters,wait)}// ...iflen(l.queues)==0 {for_,wait:=rangewaiters {close(wait)}waiters=nil}

But it's not quite as nice when retrofitted into the mutex style loop.

The problem there is that it requiresSendLoop to actually be running in order forWaitUntilEmpty() to return, which it might not be but we are still empty.

Channels are great for communicating between goroutines. Here what we really, actually want is to know when acondition is satisfied, regardless of other running goroutines, and for thatsync.Cond is your friend.

We don't actually need this check, this way we give priority to the context cancellation, even if we happen to be done at the same time (this can be preferable in some cases).