Hi
I've spent a little time again working on this wxwidgets bug. I have pretty
much done the bulk of it now. However, I had a question that people on the list
might be able to help with.
It seems that the wxWidget driver is set up to enable it to receive col0, col1
and width commands ahead of initialisation of the driver. Is this actually
possible? I thought that the initialisation should be the first thing to be
done? I'd like to remove some of this code if possible as it adds additional
complications to dealing with changing page that are a pain to work around so I
thought I'd check if they were necessary.
Cheers
Phil
________________________________
From: phil rosenberg <[email protected]>
To: Alan W. Irwin <[email protected]>
Cc: PLplot development list <[email protected]>; Andrew Ross
<[email protected]>
Sent: Monday, 11 March 2013, 11:13
Subject: Re: [Plplot-devel] [ plplot-Bugs-3604554 ] wxwidgets window
Hi All
I'm still working through the wxWidgets bug, implementing multithreading. I
already reported a possible snag with race conditions with users setting
specific keyboard actions. However i've come accross a rather larger snag.
Calling plRemakePlot also generates a race condition, perhaps in some very
complicated ways. From a quick look at the code there is some attempt to
protect the buffer from being written to while it is being read. However a
number of problems can occur. If the main thread calls plbuf_save while the GUI
thread is running plRemakePlot then the plbuf_write and plbuf_read flags will
be set in both functions causing them to be reset before one function has
finished - i guess it's quite likely that a segfault can occur in such a
situation.
Also if the main thread attempts to draw while the GUI thread is running
plRemakePlot then it looks to me as though various functions in plcore.c will
check plbuf_write, find it is false and not write their commands to the buffer.
This will presumably cause odd rendering bugs.
There is even a comment in the plRemakePlot source saying
// Change the status of the flags before checking for a buffer.
// Actually, more thought is needed if we want to support multithreaded
// code correctly, specifically the case where two threads are using
// the same plot stream (e.g. one thread is drawing the plot and another
// thread is processing window manager messages).
If we want to have multithreading work correctly then this is the time for more
thought. Does anyone have any suggestions? There are a few ways I can imagine
making things work - I don't know how well each wil function or which will be
best but i thought I'd throw them out as ideas for comment.
1) Try to threadsafe the plstream and/or the plbuf_buffer. Probably a good
solution, but a lot of work and difficult to do in a cross platform way.
2) Create a function that creates a snapshot of the plbuf_buffer in a
threadsafe way. This is also not very easy as the buffer could get reallocated
during the copy or commands without data could be included without some sort of
mutex. Again cross platform multithreading becomes an issue.
3)The wxWidgets device maintains its own version of plbuf_buffer. Could this be
done by having the wxWidgets device have a local PLStream that it can use to
call the functions in plbuf? This would allow code reuse. There is increased
memory use here but it could be that this is the least work.
Any other suggestions or comments?
Phil
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and
their applications. This 200-page book is written by three acclaimed
leaders in the field. The early access version is available now.
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
_______________________________________________
Plplot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/plplot-devel
