I have a couple of classes with the same @:build macro defined. Inside the macro’s code, a static variable is used to cache some data, so that it doesn’t need to be calculated over and over again. I discovered that the cache seems to be incomplete when the second run of the @:build macro starts, as if the first run of the macro had not yet finished. I also added some trace() calls that include unique information to identify each run, and that seems to confirm that both are running at the same time. Is this expected? Should I be using something like a Lock or a Mutex in the @:build macro, if I want to ensure that they wait for the cache to be ready?
Maybe Build order helps describing what’s going on, and Persistent Variables help with caching data?
1 Like
Unfortunately, the apparent race condition happens when building in a terminal without a completion server, so persistent variables probably won’t have any effect here. Regardless, I tried marking the variable @:persistent, just in case, but it didn’t make any noticeable difference.
I should add that I was aware that build order should not be assumed. My build macros should be able to run in any order, but the assumption that I made was that they would run sequentially. In other words, one would finish before the next would start. However, it seems that the rules around “build order” may also include an unspoken/undocumented additional qualifier that they could also be run in parallel instead of sequentially.
I’ve never seen anything like that myself. In fact, I’ve been using a Map to cache data, which ought to fail spectacularly if threads are involved.
In my own project (using Linux, @:autoBuild, and a compile server), the 100+ trace statements showed up in the right order. I think that’s pretty definitive for my workflow, though if you can confirm it uses threads in some other case, I’ll want to know about it.