________________________________________ From: Schwab,Wilhelm K Sent: Wednesday, September 29, 2010 10:11 AM To: Johan Mazel Subject: RE: [Plplot-general] Error using threads, GTK and Cairo driver John, I would be happy with anything (Ocaml is fine) any time (not in a big rush); if you have a plan for turning it into a useful example, all the better. Your idea of a descriptor sounds reasonable. Hopefully something like that, or maybe just turning globals into thread-local items(??) will make threading easier. Bill ________________________________________ From: Johan Mazel [johan.ma...@gmail.com] Sent: Wednesday, September 29, 2010 9:54 AM To: Schwab,Wilhelm K Subject: Re: [Plplot-general] Error using threads, GTK and Cairo driver Hi 2010/9/29 Schwab,Wilhelm K <bsch...@anest.ufl.edu<mailto:bsch...@anest.ufl.edu>> Is there/will there be code somewhere? Right now, nothing is directly available. In the future, I will try to make it available. However, If you want to take a look at my code right now, I can provide you with the (Ocaml) sources. Is your code OS specific? I ask in the spirit of a Windows escapee trying to understand how to do this sort of thing on Linux. There is no urgency, and even snippets could be helpful. My code is not specific to an OS, however, I don't know wether each used library has an available version for every OS. The library that I use are lablgtk and, of course, plplot and its bindings. Should there need to be one mutex to protect the entire library? I could see it for protecting a collection of open streams, but ideally once created and until closed (global again), the streams would be freely accessible from different threads?? Bill Actually, I didn't found a way to cleanly reopen a stream after a first plinit (or plinit_cairo in my case). Therefore, I don't see how several thread could access the same plplot stream. I think the multiple access through several thread could be possible if your program would handle only one plplot stream. But even in this case, you would have to be very careful about what each thread is doing on the plplot stream. In my opinion, the hidden problem behind this is the fact that plplot does not allow the user to access a kind of descriptor on a plplot stream. The type of this descriptor could be plplot_t for example and that would allow one to use plplot in a much simpler way when dealing with GUI. I am not a specialist of plplot and its history but I think that is linked to the way plplot has originally been designed: something closer to script programming and Matlab for example than something to be used inside GUIs. In my case, I solved this limitation by destroying everything and redrawing everything again whenever I want to draw something on a curve. Same thing apply when I am handling signals for GTK (expose, etc...). I basically tried to build something on top of PLplot that would allow me to use something similar to the couple Qt/Qwt. On a long term perspective I have really no idea of the interest of this solution. The main problem being the lack performance induced by the full init/redraw in case of modifications. A much cleaner solution would be to use descriptor as I previously stated but I don't know whether plplot is heading towards this. Regards. Johan Mazel ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
