[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