Heisenbug... what to do?
[email protected] Wed, 15 Jan 2020 17:31:18 +0800
| Newsgroups | gmane.comp.audio.supercollider.devel |
|---|---|
| Message-ID | <CAFniQ7VptQmO=+X=pNykCkizEUs3_heSJq5_thHcYW4SvgryWA@mail.gmail.com> |
I've got a case now where the code works when I include debugging posts, but doesn't work when I remove them. This, of course, makes troubleshooting difficult because I don't have any visibility into what's going wrong. (The presence of an observer alters the system being observed.) Backstory: I found a race condition in the newly-added MeterSync class. Since it's fresh in my mind, I wanted to test an approach that might resolve it -- each sclang instance keeps a list of MeterSync IDs, in order of creation, and any new MeterSyncs to join the network will sync up with the oldest responding MeterSync instance. (If the oldest one drops off the network, then it will stop responding and the "oldest responding instance" would be the second one that was created, and so on.) https://github.com/jamshark70/supercollider/commit/0a90851263bb56f106a263e51f74b31f530b01e4 It looks like, if I comment out the debugging posts in this commit, the IDs get out of order and the instances sync to the wrong clock. But... why? Maybe posting causes the timing of outgoing OSC messages to be just slightly different (which might affect the order in which messages arrive at other clients)? And how to prove it, if it only happens when it's not being watched? I'm a bit stuck here. hjh _______________________________________________ sc-dev mailing list info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/ search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/