Re: handle graphics

[Paul Kienzle]

There were some issues I had four years ago in which the X server would 
give strange errors if the oct-file was compiled with threads but 
octave was not.  IIRC, it had something to do with whether the C 
library was compiled with threads.  This may not be relevant today, but 
it is something to watch out for when you are experimenting.  See the 
crufty code in octave-forge/extra/tk_octave for an example.  Note 
though that this code does not handle memory in a thread-safe manner.

I would argue for threads over shared memory for much the reason Paul T 
gives below, with the added advantage that it will work natively in 
Windows without cygwin.

- Paul

On Jul 15, 2005, at 4:44 PM, Paul Thomas wrote:

> Shai,
>
> > of data to be plotted. Shared memory seems the most natural, but I'm
> > not sure it quite works on cygwin.
> It works fine, as long as the required services are up and running. 
> This is not the default but can easily be added to profile files. 
> There is quite a lot about this in the Cygwin documentation.
>
> I wonder if threads would not be better?  Thread safeness is not a 
> problem, if each thread uses a different io resource.  If the octave 
> thread holds the console window and each other thread a different 
> graphics window, things should run smoothly.  The common memory and 
> signalling is a matter of design but would not be different to shared 
> memory.  Since the system overheads are less, threads should offer a 
> performance advantage.
>
> Paul T