That is correct. I should have made this clearer; the intent is to fire a notification when the cache has changed since the last time it was sent to the client, knowing how many times it has changed (for example while it's being transmitted a whole bunch of changes may have been applied) is not important.
On Thursday, 30 November 2017 23:16:57 UTC+11, Dan Mullineux wrote: > > The for loop in the main goroutine will lose individual notifications > between each Register in that loop but it looks guaranteed that each > Register will know if at least one Notification happened after it last knew > about a Notification. So if that was, and it sounds like it was, the > intention, lgtm. > > > > > > On Thursday, 30 November 2017 05:32:10 UTC, Dave Cheney wrote: >> >> Hello, >> >> Anyone for a round of code golf? >> >> I'm working on a piece of code for a streaming gRPC server and have found >> myself in the position that I need to wait for a notification event (in >> this case that a cache has been updated and I need to stream the results to >> the client) or a context.Done event. There may be multiple gRPC clients, >> and they may come and go without warning. Thus I'm in need of a sync.Cond >> type that works with select. >> >> I've coded this up, which appears to do the job >> >> https://play.golang.org/p/pMZHwA1AD- >> >> But I'm wondering if others have found themselves in the same position, >> and if so, what were your solutions? Am I missing something, will my cond >> loose notifications, or can it be simplified? >> >> Thanks >> >> Dave >> > -- 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. For more options, visit https://groups.google.com/d/optout.
