Thanks for all the comments.
I'm now added wrapped outlet calls with sys_lock() and sys_unlock().
The reason I was getting a constant segfault in listconfig (and not in the other functions) was that I was calling the thread function, not the wrapper!
So I've checked gphoto into svn, under "bbogart".
Lots of extra features to add, but this is a decent base that allows a linux user to control a supported PTP camera from PD.
Should I put a sys_lock() and sys_unlock() for each post() and error() call?
Feel free to tinker with it, writing the "TODO" now.
.b.
Mathieu Bouchard wrote:
On Thu, 19 Mar 2009, B. Bogart wrote:
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?
Well, in the same way that when a [delay] or a [metro] outputs a bang it "interrupts" the rendering. But those events are never nested nor overlapping in real time, so a block always finishes computation before something else happens, and a message sent from [delay] always gets "fully processed" before something else happens, and so on. It wouldn't be much different from what you'd get if you turned the 2nd thread into a separate server that you'd communicate with using [netsend], really.
The only thing is that sometimes, pd runs in the 2nd thread, but that doesn't make so much of a difference, as pd is then not running in the 1st thread at the same time. The question is not which thread is in use, but how many of them at a time.
Replacing the lock by a message queue could have had some advantages, but it's more work.
Ah! I would only need to lock while before I do the PD calls right? sys_lock(); outlet_symbol(); sys_unlock(); ?
Exactly.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec