Hi,
Il 11/06/21 07:45, Nikolay Sivov ha scritto:
You can easily check that. Default event queue implementation uses standard system queue, which is single-threaded. Since you queue events always from the same thread, I think they might get in order. My main concern is to get session working correctly in this case, when source state has not fully transitioned, but samples are coming already.
I wrote a test program on Windows that spawns two threads, each of them getting events from a queue; a third thread posts events on the two queues, first the first queue and then the second queue. The results confirm my hypothesis: in a significant amount of the tests, the second thread processes the event before the first queue, even if the even on the first queue was posted before.
This is expected: even if the event queues are globally single-threaded, the two threads waiting on them are not by definition; thus even if the first event is guaranteed to be processed before the second one (which in itself is not a guarantee I'd give for granted), the operating system can very well decide to unschedule the waiting threads while they're just about to process the event, so in practice any order can happen. As a matter of facts, I don't think it is even sensible to speak of "order" between two threads, unless there are synchronization points.
If our session depends on stuff happening before other without this being regulated by a synchronization point, then our session has bugs, and we should fix those instead of hoping that the operating system will always cooperate.
Giovanni.