so, i finally fixed the runaway CPU usage thing
first of all, what was happening was that when a query finishes the channel closes which means it keeps emitting a zero/nil value, which was happening billions of times a second
second, after that, was that then i had a problem of when to close tho top level channel only after both #layer2 query channels also closed
then once i got that fixed, then i had the problem of one channel closing before the other even started causing the main channel to be closed before it got to send its message
so, it required two waitgroups, a start waitgroup and a finish waitgroup
before the main composite query goroutine terminates, first it waits for both receiver goroutines of each layer of the database back end to start, because if they don't both start first, then the finish waitgroup can go to zero and then close the channel before the second receiver starts
and part of the reason is by necessity, to get the channels for each listener goroutine, first the queries have to be spowned to get the channel come back, that is listened to on each goroutine, so the start has to be synchronised with the finish before the finish should pass forward
i had written similar kinds of code before, you can also use a simple channel if it's only one goroutine being spawned but for two, like this, you have to use a waitgroup because if you wait on two signals you have to synchronise to when both signals have happened and waitgroups use semaphores which are the most lightweight sync primitive - it's the underlying sync primitive in the runtime along with channels - everything else, atomics, mutexes and waitgroups all are built upon these two things
#devstr #replicatr #layer2 #deardiary #devdiary
Showing page 1 of
1 pages
