Hi Krzysztof,
There are the sys_lock and sys_unlock API functions that guarantee that
a
locked zone can only be active when PD is idle (is microsleep).
ok, I should have done my homework first... still, I am not sure the lock/unlock calls I can see in my copy of Pd scheduler are not misplaced. I think, all the external messages, like gui events (mouse and keyboard), net receivers, pipes, etc., are being polled into Pd via the microsleep routine, so they seem not to be locked out by the other thread?
Hmmm, i think you are right, but the question is if these can really collide with the threads used by PD externals. I think i remember that it was Miller's suggestion to place them there and i hope that my lack of insight into the PD internals didn't mix things up here. It's a good thing to reconsider the whole construction since threads are used more and more these days.
In flext there's a message queue for all messages from non-PD threads or
for
Forgive me, but I still do not understand it fully. One thing, simple and robust, is queuing messages, and arming a clock, for dispatching them in the main thread. However, if we are to distribute message passing among different threads anyway, what is to be gained, in the real world, by using the background dispatcher, instead of each thread locking Pd when issuing its message?
The gain is that the routines using the message don't need to wait for the thread lock to open. I have to admit on the other hand that i was lazy doing profiling... that's what still has to be done. Since practically all important features are readily implemented, maybe it's the time to do so now (after the summer vacation).
best greetings, Thomas