From maintainers-request at octave dot org Sat Jul 16 08:31:49 2005 Subject: Re: handle graphics From: Shai Ayal To: Paul Kienzle Cc: "Octave's maintainers list" Date: Sat, 16 Jul 2005 15:30:44 +0200 In any case (threads or not) a two way protocol should be established & DOCUMENTED so that people can start writing graphic fronts. The handle graphics structure should be 1. unique 2. global 3. read only as a structure, i.e. everyone should be able to do "fieldnames(figure)", but not figure.axes = 15; 4. changeable only the "set" command which will also to all the type & consistency checks. It seems to me that 1 & 3 cannot be achieved using the interpreter alone. Once they are done using c++, 2 is trivial and 4 can be done using m-files. So we do need a new custom type which gives us 1 & 3, but from the examples I have seen already (CMO & oplot) this seems to be doable. As I noted before the bulk of the work is 4! Shai On 7/16/05, Paul Kienzle wrote: > 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 > > > > > >