[PD] Externals with threads ...

Thomas Grill gr at grrrr.org
Tue Jan 25 10:53:26 CET 2005


> > I'm wondering what peoples opinions are on the subject of externals
> > with their own threads. Are there reasons this is is not advised (e.g.
> > reentrancy of subsequent calls)? To be specific I'm talking about
> > threads that initiate output. I've looked at the sourcecode for
> > netreceive and noticed the use of sys_addpollfn, but as this method is
> > not included in m_pd.h, i wonder if it's even intended to be used in
> > externals. One of the reasons i ask is that the example/test code
> > attached bellow seems to work on one of my machines (Pentium 4/Fedora
> > 2/PD 0.37.1), but when I run it on another (a PowerbookG4/Gentoo/PD
> > 37.4) I get a stack overflow at the outlet_float.
> well ... the only threadsafe way to synchronize helper threads with the
> main pd thread is to place callbacks in the scheduler.

Hmmm, that's not exactly true.
flext has been using the sys_lock and sys_unlock calls of the PD api before
the advent of sys_callback in devel_0_38. This is also threadsafe but
_might_ hold the main pd thread for too long a time (although i never
encountered this).
The point is that in your secondary thread you are locking PD with sys_lock
whenever you want to use PD API functions (like getbytes or outlet
functions) and unlock it with sys_unlock when done. Clearly this time should
be as short as possible. This ensures that your calls into PD happen when PD
itself doesn't do that (as it is in "idle" state).
Starting with devel_0_38 it would be better to use sys_callback, of course
since there's no locking involved.

best greetings,
Thomas






More information about the Pd-list mailing list