From graphics-request at octave dot org Wed Mar  1 02:14:56 2006
Subject: Re: GUI thoughts
From: kraiskil at cc dot hut dot fi
To: "John W. Eaton" <jwe at bevo dot che dot wisc dot edu>
Cc: Sebastien Loisel <sloisel at gmail dot com>,         octave graphics and gui mailing list <graphics@octave.org>
Date: Wed, 01 Mar 2006 10:09:07 +0200 (EET)

Hi, 


On Tue, 28 Feb 2006 20:44:35 -0500 "John W. Eaton" <jwe at bevo dot che dot wisc dot edu> wrote:
> On 28-Feb-2006, Sebastien Loisel wrote:
> 
> | 
> | That's not correct. I will have to wait until eval_string returns
> before I
> | interact with Octave again, but the GUI itself can keep going. Which
> is what
> | Kalle is working on. Which is what you said afterwards. Ok.
> 
> OK.  If people are working on things that involve Octave internals
> (and I don't see how threading could not) then they should be posting
> ideas about implementations here.  

I'd love to see Octave thread safe. In order to take advantage of
dual core processors and all that. But as long as it is not, concurrency 
must be hacked in. What I've done in yaog (yaog.sf.net) and proposed to 
Octave-workshop is that Octave runs in a separate thread, with all the 
synchronization issues contained in the GUI/IDE. 


> I saw one proposal from John
> Swenson about passing data to and from Octave, but I'm not sure that
> this is really what we are looking for.  The proposal was to check in
> a few locations like the main loop or anywhere a breakpoint can be
> set, but that doesn't help with long-running calculations in compiled
> code.  Octave would still be unresponsive during those times.

This proposal moves the thread synchronization to Octave which is an
improvement, because the "plain Octave binary" could be used (as done
in yaog). This is nicer than calling liboctave directly, because
you have the "look 'n feel" of the terminal application. 


> 
> | If you want to make Octave thread-safe, that would kick ass, however
> if I
> | were tasked with doing it I would be apprehensive.
> 
> Why?  Is it because you are unfamiliar with Octave internals, or
> something else?  I'm familiar with the internals, but don't know much
> about threads.  Is it possible to use (approximately the same
> threading model (whether or not it is precisely the same set of
> function calls) on POSIX and Windows systems?


This would be the third, and by far best alternative. But I also fear that
making Octave truly thread-safe could be a big issue. (Discalimer: this is
because I'm unfamiliar with Octave internals. Perhaps it is only a matter of
protecting the symtab?) 
There are portable threading libraries out there, but I could imagine POSIX
threads is something MinGW would implement. Making the Octave internals use
these would be the challenge, I think. 


What would it take to make Octave thread-safe?

Kalle