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
have had a very productive day, squashed multiple bugs
at the end of the day i have been reminded how to write and access CPU and heap profile data with #golang as i have some infinite loop or something in some of the new #layer2 two level event store management query events method
shouldn't take me long to audit it and snuff it out and then hopefully i'm looking at a stable release bump to v1.3.0
and now, i feel like playing some games
oh yes, also, the flat tire on the bicycle, pumped it back up and so far doesn't seem to actually be leaking now, so, no idea why that is, maybe some problem with the valve being kinked or some other kind of pinch or whatever
got plenty of patches to apply if it does turn out to be busted, and very nearly found the right size tire tube at the local gas station but unfortunately only in 1.75" wide not the 1.95" wide that my bike has
i'll find the right ones in the next day or two... in any case i prefer the wider wheel, the roads here are pretty wild, plenty of opportunities to blink and wind up falling down a 10 foot drop ... so good traction and good brakes are essential
probably will take it to a bike workshop maybe this weekend and just get it all tweaked, trimmed and oiled properly
this one will do me for some time but i can see myself very much wanting to build something from parts later, out of a super light weight freestyle bike and put regen brake on the front and sling the battery lower, and a little bigger and have spokes instead of alloys and probably run them with lower air pressure and get a decent rack on it
anyway, it's enough for now, and fun
#replicatr #devstr #deardiary
after fixing up a heap of little problems and nailing the json string escaping problem today i feel a lot closer to a real release for #replicatr
it's almost ready to go out into the big wide world by itself
i just want to see it swallow this whole 180gb of events first without blowing up, and i've been cleaning out the code, removing redundant pieces, and i think maybe over this weekend i might get started on some documentation and polishing the UX of relay operating with it...
for the most part, configuration and such has been an afterthought but especially today it became clear how the configuration system needs some love but i wrote it as simple as i could so it would be reliable
the everpresent satanic temptation to add features to things is real, folks...
always question every time you think "oh but this feature that feature" no... no feature, fix the bug first, make the features in it work better, then dig deep down and ask yourself, "am i just showing off? is this from other people telling me this thing would be cool? is this making me neglect important things like documentation?"
adding features should be only when you have not just an MVP but a sleek, teflon coated, nanometre tolerance engineered machine that does the thing
and then you should consider whether it would be better to make the feature another application completely
Showing page 1 of
2 pages
