[PD-dev] stack checking
gr at grrrr.org
Thu Jun 24 15:08:44 CEST 2004
> > There are the sys_lock and sys_unlock API functions that guarantee that
> > 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
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
> 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).
More information about the Pd-dev