[PD-dev] Using PD funcs from inside a threaded external

Thomas Grill gr at grrrr.org
Thu Mar 19 19:22:13 CET 2009


Hi Ben,
if it's just about sending messages to outlets, you could also use a  
lock-free fifo to queue up the messages (in the second thread) and a  
timer to send out the elements to the outlets asynchronously (pd  
thread).
That's what flext does internally.
gr~~~

Am 19.03.2009 um 17:28 schrieb B. Bogart:

> Thanks for the comments Tim & Mathieu,
>
> It seems I have two options:
>
> * Not send output to PD (very limited functionality)
>
> * Use Tim's suggestion.
>
> Mathieu Bouchard wrote:
>> Afaik, this will do the rough equivalent of a [delay 0] across  
>> threads,
>> so that your (Ben's) thread's execution is inserted between two  
>> t_clock
>> events ([delay], [metro], etc.)
>
> Does this mean that rendering/audio in PD will be interrupted during
> this time of global locking?
>
> Ah! I would only need to lock while before I do the PD calls right?
>
> Something like:
>
> sys_lock();
> outlet_symbol();
> sys_unlock();
>
> ?
>
> Thanks!
> .b.
>
>
>> On Wed, 18 Mar 2009, Tim Blechmann wrote:
>>
>>>> The problem is that I've approached all the gphoto calling  
>>>> functions the
>>>> same, but one particular function (listconfig) segfaults when I  
>>>> use PD
>>>> functions, in particular outlet_symbol().
>>>
>>> when calling pd's api functions from a separate thread, make sure to
>>> hold the global pd lock ...
>>
>> Yes, sorry, I should have known.
>>
>> This is sys_lock() and sys_unlock() if pd is compiled with
>> THREAD_LOCKING enabled.
>>
>
>>
>> _ _ __ ___ _____ ________ _____________ _____________________ ...
>> | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
>
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev





More information about the Pd-dev mailing list