From octave-graphics-request at bevo dot che dot wisc dot edu Thu Jun 27 14:33:57 2002
Subject: Re: GTK and Octave
From: Paul Kienzle <pkienzle at jazz dot ncnr dot nist dot gov>
To: "John W. Eaton" <jwe at bevo dot che dot wisc dot edu>, Jo?o Cardoso <jcard@fe.up.pt>
Cc: octave-graphics at bevo dot che dot wisc dot edu
Date: Thu, 27 Jun 2002 15:33:42 -0400

On Thu, Jun 27, 2002 at 12:47:22PM -0500, John W. Eaton wrote:
> On 27-Jun-2002, =?iso-8859-10?q?Jo=E3o=20Cardoso?= <jcard at fe dot up dot pt> wrote:
> 
> | On Tuesday 25 June 2002 00:12, Ben Sapp wrote:
> | | Hello,
> | |
> | | I have written a class and some DLD functions to accompany the class
> | | that allow a person to bring up most GTK widgets from within Octave. 
> | |  I also have a callback implementation working.
> | 
> | Hi,
> | 
> | I didn't compile your gtk_octave, only quickly browse the code.
> | 
> | Again an Octave deficiency arises, as the gtk main loop is only called 
> | during "Octave idle time", i.e., while Octave (actually readline) waits 
> | for user keyboard input:
> | 
> | /* This is called during octave idle time */
> | extern int
> | event_hook()
> | {
> |   while (gtk_events_pending())
> |     gtk_main_iteration_do(FALSE);
> | 
> |   return 0;
> | }
> | 
> | What happens if the user hits a button which deploys a lengthly 
> | calculation that afterwards the user wants to cancel hitting another 
> | button? Nothing, the current calculation has to finish until the new 
> | button is recognized (or the user code has to check regularly for the 
> | new gtk event, which is not a very clean approach)

Or you let Ctrl-C return you to the octave toplevel just as it does now.
Not as pretty as a Cancel button, but it is available now.  With backing
store on the graphs so that you can uncover and see them while octave is 
busy, then maybe blocking the GUI during callback isn't so bad.

> | 
> | This can be avoided only if event_hook() is also called during Octave 
> | processing. Without knowing enough about Octave "insides", it looks to 
> | me that the only "safe" way of doing this is for Octave to call 
> | event_hook() when the parser hits a "terminal symbol".
> | What do you think about this?
> 
> How would this help in the lengthy calculation example?  In that case,
> Octave would be off processing some long-running calculation so there
> would be no terminal symbol for the parser to hit.

I agree.  Consider:

	octave:96> a=rand(300); b=rand(300);
	octave:97> tic; a*b; toc
	ans = 21.038

Do you really want to slow down BLAS code by putting an event check in
the matrix multiply?  

> If you were designing Octave from scratch with event handling
> (keyboard input, mouse clicks, signals, something else?) in mind, how
> would you do it?

Since the atomic operations are so large, you can't do cooperative
multitasking in octave (i.e., by inserting process_event_loop calls in
your scripts), so you are left with preemptive multitasking (i.e.,
threads), and all that that entails:
	* each callback running in its own thread since you don't know
	which callbacks are going to take a long time.
	* managing a pool of threads because you don't want to create
	and destroy one on every call.
	* making sure that all static data is thread local (including
	the stuff in libcruft --- aren't all fortran variables static
	by default?)
	* making sure all shared data is protected by mutex (including
	file access, symbol table access, etc.)
	* deciding what to do with state variables that modify octave's 
	behaviour.  What if one thread wants colormap(gray) and another 
	wants colormap(ocean).
In fact you will have to deal with most of these issues even with 
cooperative multitasking, assuming things like read process the event
queue until data is available instead of blocking the entire process.

Paul Kienzle
pkienzle at users dot sf dot net