From: ramsdell ()
Date: Dec 2, 2004
Subject:
Concerns about FLrun, flCsound, and threads
"Art Hunkins" writes:
> GBS7 is indeed out, and I can verify that it now handles both FLTK
> and MIDI correctly in live performance (Windows). And this both in
> the command-line Windows version and in flCsound.
Glad things are working for you. I am confident that console csound
correctly handles orchestras that contain the FLrun opcode, but the
same cannot be said for flCsound. I'm wondering if anyone else agrees
with my concerns.
The flCsound program is designed for use in a single threaded program.
When the csound engine is rendering, the GUI remains lively because it
registers a yield callback that checks for GUI events when the engine
yields. The key point is the events are handled by the thread running
the engine.
When FLrun is executed, it spawns a new thread that goes into an
infinite loop. It waits until a GUI event is available, and when one
appears, handles it. Thus, if flCsound is rendering something that
executes FLrun, events will be non-deterministically handled in one of
two threads. The flCsound GUI code was written with the assumption
that it would be executed by at most one thread at a time. I bet the
FL opcodes make the same assumptions.
Art's experiences suggest to me that during his runs, both flCsound
and FL opcode events are usually handled by one thread while the other
thread either waits, or renders. My concern is this behavior is not
guaranteed. See what I mean?
Of course, if "usually works correctly" is good enough for you, than
by all means, use flCsound with orchestras that contain FLrun.
The graphing routines may have the same problem, but one can simply
turn them off using the -d.
John
-- [EMAIL REMOVED] (or to http://www.cs.bath.ac.uk/cgi-bin/csound ) [EMAIL REMOVED]