I attach a simple patch where I sometimes get a behaviour I can't explain.
I (think I) make sure to do things in a certain order and it seems that they sometimes happen in reversed order, so I can't understand what I am doing wrong.
Please look at the attached patch: expected vs observed behaviour is detailed in the comments inside the patch, and the patch is extremely simplified.
The only explanation I can find is that when you send a message to a matrix (such as the output of another matrix, or a setall message) that is supposed to perform a write operation on that matrix, it is not guaranteed that this operation is atomically performed before any other message arrives to the same matrix. That is, if a second message arrives after the first one (obviously in the order of milliseconds after or less), the write operation of the second message MAY be performed before the write operation triggered by the first message.
It seems to me that it shouldn't be so... but that's what I am observing.....
Can anyone confirm my analysis? Or point out what's wrong in the patch?
In case this is correct, is there a way of ensuring "atomicity" of operations in the sense explained above (and in the patch)?
I can program in such a way to always ensure that max events (i.e. bangs, messages etc) are delivered in the order I need them to be delivered, but if I cannot trust that the operations they perform are then executed in the same order, well, programming is gonna become quite complicated ;)
If it is so, I'm sure a lot of people must have faced this "problem" and can suggest frameworks and techniques to make things easier.
Note that in the attached example, I may easily re-draw the black square at every frame when the big toggle is off, but I want to avoid unnecessary cpu-consuming operations such as keep refreshing matrix data that I know is not changing.
Thanks in advance
matteo sisti sette