Widgets.cpp on csound5 uses Fl::lock etc.

I don't think the FLTK lib check is needed, because csound5
will not build properly if FL::lock() is not there. 
I was working on acsound5 linux build, and I was unaware
that I needed to configure --enable-threads (or whatever)
when building the FLTK lib, I thought
that was the default. Then I could not build csound5
with FLTK, because of the missing methods.
With it in place, all was well.  

In the FLTK distro there is a little test program showing
the use of Fl::lock() and colleagues. That's
how I found out that the multithreading was not 
enabled.
 
On windows FLTK builds with thread support by
default. This doesn't seem to b the case with 
linux. The configure script should pick up the
presence of the pthread lib and enable it, but
it doesn't. 

What we need is a readme file somewhere telling
people all this, otherwise everyone will be losing
their time finding out what they need!

Victor

 
> Also note that I updated Csound4's configure.ac file so
> that it probes the FLTK library to see if it was compiled
> with thread support enabled.  When it is, it defines
> HAVE_FL__LOCK.  The configuration system for Csound5
> should make an equivalent check.  The file
> flcsound/src/main.cpp contains the code that generates a
> version of flCsound that is either single or
> multi-threaded, based on HAVE_FL__LOCK.
> 
> To fix the threading problem, I suspect csound/widgets.cpp
> will have to changed so that the code in it employs the
> same tricks used by flCsound's main routine, that is, the
> code will have to be conditionalized on HAVE_FL__LOCK.
> 
> John
> 

Victor Lazzarini  writes:

> Widgets.cpp on csound5 uses Fl::lock etc.

This made me optimistic that one need only back port the Csound5
version of widgets.cpp to Csound4, but after reviewing the file, I
don't think it's that easy.  This code puts an Fl::lock/Fl::unlock
pair around two occurrences of Fl::wait.  That's because there are two
threads that perform an Fl::wait!

Once again, this is bad news for CsoundVST and flCsound.  My reading
of the FLTK manual says that only the main thread is permitted to call
Fl::wait or Fl::check.  And there is another potential problem.  FLTK
accesses in child threads should be surround by Fl::lock/Fl::unlock
pairs, but the main thread should call the Fl::lock once, and hold the
lock.  The routines in the Csound5 version of widgets.cpp are
appropriate for use in child threads, but never as the main thread.
My question is, what happens when Csound5 is run in console only mode?
What thread is the main thread?  It cannot be the one that runs
fltkRun, as it drops its lock after each call to Fl::wait.

> I don't think the FLTK lib check is needed, because csound5
> will not build properly if FL::lock() is not there. 

I don't understand why one cannot design Csound5 so that it can be
built when FLTK is available only as a single threaded library.

Once widgets.cpp is multi-threading enabled in Csound4, the Csound4
autoconf script will be changed so it only builds libcsound with FLTK
routines when the FLTK library supports multi-threading.  It will
build flCsound whenever FLTK is present.  The single threaded version
of flCsound works just fine in this case.

John