-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/21/2011 09:26 PM, Louis-Philippe wrote:
Hi PD-Dev Peoples,
I was wondering how I should deal with async callbacks inside an external? What I have in mind:
- message sent to external inlet
- external proceed to trigger some blocking io with async callback
- external sends trigger status on outlet
- ticking continues
- the blocking io answers with the callback
- the external sends result to outlet as result of callback
anybody has a take on these?
i use this quite a lot, most prominently probably in "Gem" (which has a big code-base; a good start would be Gem/Workerthread.cpp and Gem/SynchedWorkerThread.cpp) and in "iemnet" (much smaller; in C)
the callback-code usually looks like: 1. push the data retrieved async into a (threadsafe) queue 2. notify Pd to do a sync callback using clock_delay(x, 0) note that clock_delay itself is not threadsafe (there is a patch in the sftracker), so you have to protect it using sys_lock() and sys_unlock() 3. when Pd calls back within the main thread, pop the data from the queu and send it to the output
a more (too) naive way would be to just run outlet_foo() from within the async callback and protect that with sys_lock()/sys_unlock(); which is usually less performant as the above, esp. if the async callback might be called quite often.
a more elaborate way would be to reduce the calls to clock_delay() even further (as you don't need to call it again, if it has already been called and not reacted upon yet)
in general you have to be aware, that virtually all functions in Pd are not threadsafe (e.g. don't use gensym() from within your async callback!), and the only way to deal with that is using the BIG KERNEL LOCK with sys_lock() / sys_unlock()
fgmasdr IOhannes