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