Besides, both Rory Walsh's intro and The Ubiquitous Slider Demo (http://www.csounds.com/journal/2006summer/SliderDemo.html) shows some liberal uses (in the same sense as above of invoking it from another thread) of csoundGetChannelPtr. Probably csoundGetChannelPtr, as innocent looking as a function can look, is thread safe. But what if I change a channel value from v1 to v2 during performance, and -say- an opcode assumes v1 while another, executed later during the same iteration, assumes v2? An unexpected output could be produced, thread safety issues apart. Wouldn't it be safe to avoid these unsynchronized calls? Regards -Carlos On Sun, Oct 19, 2008 at 10:50 PM, Carlos Pita wrote: > Hi, > > the last example in Rory Walsh's intro to the csound api creates a > csound thread and then calls csoundScoreEvent from the main thread > without taking further precautions, while > CsoundPerformanceThread::ScoreEvent implementation enqueues a message > that is later unqueued by the performance thread, all in a perfect > thread-safe way. What is the real truth? Is csoundScoreEvent > thread-safe or not? In general, what thread safety warranties can be > assumed for the api? > > Best regards > -Carlos > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net