looking at widgets.cpp, it seems we are doing everything that the
FLTK designers do not allow or guarantee, when using threads.
We are calling show() and wait(). The whole design of the
thread-based code seems to be wrong. I am also wondering whether
it is possible to do what we want with the widget opcodes
in a multithreading fashion. Either we change the code or we just
scrap it. The way it is written it is not guaranteed to work.


Victor Lazzarini
Music Technology Laboratory
Music Department
National University of Ireland, Maynooth 



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I see your point. I think the noFLTKThreads=1 should be the
standard. I have tested it here and it works OK on all OSX
platforms (including your changes from yesterday).
I think in fact that we should remove the threading code as
it is not guaranteed to work and it probably only works as a side-effect.
See another reply from the FLTK guy:

On Nov 30, 2005, at 1:19 PM, Victor lazzarini wrote:

 > Does it mean that Fl::wait() cannot be called from
 > a child thread?

Yes. If it does work on Win32 or Linux, then you may be just lucky.
It may not work on the next computer with a different core, X11
server or, in case of MSWindows, Service Pack.

 > My problem is that the code we have been using works on
 > all platforms except OSx 10.4. I have it running on
 > Linux, Windows and OSX 10.3.

You may be lucky with the current SVN Snapshot for OS X. Still, I
would really like to convince you of not using wait() etc. from a
thread other than the main thread. It may work, but only as a side
effect.

Matthias

The original threading code might break anytime. I would vote for it to
be removed. Unless someone wants to spend time devising a way of
doing it properly.

If Csound is used in a a multithreading application, then FLTK widgets are 
out of
the picture. It is not a problem, I think, as FLTK have been taken out of 
the core csound
library and is supplied as plugins. Someone else might supply other plugins for
graphics based on other library. And in the case of frontends, graphics 
might be
supplied by the frontend itself (cf. cswish).

Victor

At 13:48 30/11/2005, you wrote:
>Actually, the restrictions on threading are a major problem, as
>Csound itself can be a plugin of some other software, and then
>there is no way to guarantee that it is running from the main
>thread. Also, even in the case of a simple command line build
>of Csound, it would mean that if threads are used, then the audio
>thread (which does not call Fl::wait() to update the GUI, that is
>the whole point of using two separate threads) should be the child
>thread, but that is quite the opposite of how Csound is designed
>(i.e. start audio processing in the main thread, and then
>optionally create widgets at a later point in time with opcode
>calls). So, for safety we can stick with the noFLTKThreads=1 mode,
>which should work (but if even that breaks on the Mac then I
>really do not know what to do) as long as Csound is being run in
>the main thread and nothing else uses FLTK in the same process.
>The multi-threaded code can still be used on platforms where it
>works, though.

Victor Lazzarini
Music Technology Laboratory
Music Department
National University of Ireland, Maynooth 



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I  had the impression we had threaded this path before, and yes,
we did. Here's some messages from John Ramsdell in January,
which address the problem (where is he? he seems to have gone...)

On hacking FLTK:

http://article.gmane.org/gmane.comp.audio.csound.devel/3081/match=fltk+bug

On a FLTK bug, reported:

http://article.gmane.org/gmane.comp.audio.csound.devel/2842/match=fltk+bug
http://article.gmane.org/gmane.comp.audio.csound.devel/2854/match=fltk+bug
http://article.gmane.org/gmane.comp.audio.csound.devel/2859/match=fltk+bug


In relation to keeping the threading code: is it safe? Can we guarantee it
will work? If so, it is OK. If we do not mind having hacked code, it is not
a problem.

Victor

At 16:19 30/11/2005, you wrote:
>On Wednesday 30 November 2005 16:47, Victor Lazzarini wrote:
>
> > I see your point. I think the noFLTKThreads=1 should be the
> > standard. I have tested it here and it works OK on all OSX
> > platforms (including your changes from yesterday).
> > I think in fact that we should remove the threading code as
> > it is not guaranteed to work and it probably only works as a side-effect.
> > See another reply from the FLTK guy:
>
>While the non-threading mode should definitely be the default
>on OS X, it may be worth keeping for Linux and Win32 where
>threads seem to work (and the original version in CsoundAV also
>uses threads) unless actual problems are found on those platforms.
>Using threads (where doing so works, that is) does improve real
>time audio performance, particularly when combined with the
>--sched option. Although, the single-threaded model does have
>its advantages: it allows for using widgets and graphs at the
>same time, and eliminates the need for compiling FLTK with
>--enable-threads as no lock/unlock/awake calls are used.
>
> > If Csound is used in a a multithreading application, then FLTK widgets
> > are out of the picture. It is not a problem, I think, as FLTK have been
> > taken out of the core csound library and is supplied as plugins.
> > Someone else might supply other plugins for graphics based on other
> > library. And in the case of frontends, graphics might be supplied by the
> > frontend itself (cf. cswish).
>
>Well, we do have the bus interface and chnexport etc. opcodes, but
>need an actual host application that makes it really useful in
>practice.
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>for problems?  Stop!  Download the new AJAX search engine that makes
>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
>_______________________________________________
>Csound-devel mailing list
>Csound-devel@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/csound-devel

Victor Lazzarini
Music Technology Laboratory
Music Department
National University of Ireland, Maynooth 



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

> If Csound is used in a a multithreading application, then FLTK widgets 
> are out of
> the picture. It is not a problem, I think, as FLTK have been taken out 
> of the core csound
> library and is supplied as plugins. Someone else might supply other 
> plugins for
> graphics based on other library. And in the case of frontends, graphics 
> might be
> supplied by the frontend itself (cf. cswish).

I agree. I am using csound in a multi threaded app, and with Istvan's 
help got all my fltk stuff in a seperate lower priority thread. It seems 
to work very well as the csound thread contains no fltk stuff. Nor is it 
necessary for csound to do fltk stuff because I can do whatever I would 
do in csound-fltk, in the fltk thread with api calls.

It would be nice if we could have our cake and eat it too, but I think 
it is not the end of the world ( or worth delaying a release ) if we 
have to assume that anyone writing a multi-threaded host can also handle 
their fltk stuff outside of csound.

Iain


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net