Re: [Plplot-devel] Is it time to remove some IPC cruft from our wxwidgets-related code?

[Phil Rosenberg]

On 3 October 2017 at 22:01, Phil Rosenberg  wrote:
>>> Hi Alan
>>> I have been trying to work through your semaphore code, but I'm afraid
>>> I just don't quite get it.
>>>
>>> At the heart of this bug is the fact that receiveBytes() should be
>>> able to accept a timeout for waiting for the semaphore to unlock and
>>> instead of being void it should return the number of bytes it actually
>>> read.
>>>
>>> When I tried to implement this I just kept getting deadlocks because
>>> I'm not really sure how it all works.
>>
>>
>> Hi Phil:
>>
>> Because you are having trouble understanding the transmitBytes and
>> receiveBytes design, I think the best thing to do is for me to look
>> closely at the deadlock scenario you have described previously to see
>> if the current design answers it.  And if it doesn't, I will modify
>> transmitBytes and receiveBytes appropriately.  But this all will take
>> some substantial time on my part because I have other PLplot issues
>> (such as the cross-talk between streams that some interactive devices
>> show for example 14) on my plate right now.
>>
>> Meanwhile, you did say you had some sort of fix for locate mode
>> which you (much earlier in the recent discussions between us) described as
>>
>>> I have made a quick couple of changes that makes locate work correctly
>>> again with wxWidgets by simply halting checking for new data while
>>> doing a locate, then starting again when locate is complete.
>
> Yes, plus a full fix for the old style comms. I have also realised
> that I am not correctly filling in the state variable for the locate
> info, so example 20 is still not quite working as it should. However I
> am having some trouble capturing the mouse button release. Once I have
> that worked out I will push the changes.
>
>>
>>
>> But you were reluctant to push those changes at that time, and I don't
>> think you have done so since.  If these changes do not involve the
>> introduction of timed waits or modifications to transmitBytes and
>> receiveBytes is there any reason to not push them? But if they do
>> involve such changes (e.g., to work around the deadlock you think is
>> there), then please don't push them and send me the patch instead to
>> help educate me about that issue.
>
> Yes it's a workaround rather than a proper fix. There really does need
> to be a timeout when the viewer checks for more data otherwise it
> causes all sorts of problems with possible deadlocks and also just
> unresponsive windows, i.e. resizes won't work and windows won't close
> while the viewer is waiting for the semaphore. You can see the
> deadlock by running example 20 with -nosombrero (you need this as
> there is another problem that will be fixed by the commit I mentioned
> above). You will find both sides of the communication hang. You can
> also uncomment the #define WXPLVIEWER_DEBUG line in wxWidgets_dev,
> then run x20c in a debugger - it will give you the command to run
> wxPLViewer in another debugger instance so you can see the point at
> which the hang occurs. Basically the core code is sat waiting for the
> locate data and the viewer has carried on repeatedly checking for new
> data so cannot actually collect the locate data.

I have just commited the workaround. But sadly it turned out not to be
very reliable. I'm not sure why. I am now sometimes able to get past
page 2 of example 20, but sometimes it hangs before I can leave and
sometimes it hangs later in the sequence. The non-IPC3 method is
currently working perfectly with locate.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Is it time to remove some IPC cruft from our wxwidgets-related code?

[Alan W. Irwin]

On 2017-10-03 12:34+0100 Phil Rosenberg wrote:


Hi Alan
I have been trying to work through your semaphore code, but I'm afraid
I just don't quite get it.

At the heart of this bug is the fact that receiveBytes() should be
able to accept a timeout for waiting for the semaphore to unlock and
instead of being void it should return the number of bytes it actually
read.

When I tried to implement this I just kept getting deadlocks because
I'm not really sure how it all works.


Hi Phil:

Because you are having trouble understanding the transmitBytes and
receiveBytes design, I think the best thing to do is for me to look
closely at the deadlock scenario you have described previously to see
if the current design answers it.  And if it doesn't, I will modify
transmitBytes and receiveBytes appropriately.  But this all will take
some substantial time on my part because I have other PLplot issues
(such as the cross-talk between streams that some interactive devices
show for example 14) on my plate right now.

Meanwhile, you did say you had some sort of fix for locate mode
which you (much earlier in the recent discussions between us) described as


I have made a quick couple of changes that makes locate work correctly
again with wxWidgets by simply halting checking for new data while
doing a locate, then starting again when locate is complete.


But you were reluctant to push those changes at that time, and I don't
think you have done so since.  If these changes do not involve the
introduction of timed waits or modifications to transmitBytes and
receiveBytes is there any reason to not push them? But if they do
involve such changes (e.g., to work around the deadlock you think is
there), then please don't push them and send me the patch instead to
help educate me about that issue.

Alan

__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Is it time to remove some IPC cruft from our wxwidgets-related code?

[Phil Rosenberg]

Hi Alan
I have been trying to work through your semaphore code, but I'm afraid
I just don't quite get it.

At the heart of this bug is the fact that receiveBytes() should be
able to accept a timeout for waiting for the semaphore to unlock and
instead of being void it should return the number of bytes it actually
read.

When I tried to implement this I just kept getting deadlocks because
I'm not really sure how it all works.

Can I also just check, in the end what was wrong with the previous
comms that I put in place? Didn't we eventually find that the source
of the delays was the random number generator for determining the name
of the shared memory and nothing to do with the actual comms?

On 3 October 2017 at 09:07, Phil Rosenberg  wrote:
>>
>> It is good that you are doing some critical thinking about my bytes
>> transmission logic this way.  However, it appears you are referring to
>> the case where there are two separate but simultaneous uses of IPC
>> (one to send an array of data from core to viewer and one to send an
>> array of data from viewer to core).
>
> Hi Alan
> Actually I am talking about the opposite case. Both core and viewer
> make a receive request. In both cases the receiveBytes function will
> not return until the data is received, but the other party can never
> send it because it is also sat in the receiveBytes function.
>
> Here what happens is the core sends a locate command and calls
> receiveBytes waiting for a response.
>
> The viewer receives the locate command and flags this so that we
> capture the next mouse click, however before that happens the timer
> triggers the viewer to check for some more data, it calls receiveBytes
> then sits waiting for data. But of course the core won't send any data
> until it has received the locate data.
>
> The result is deadlock and the viewer hangs.
>
> The proper fix should be that there is an option in receiveBytes to
> return immediately if there is no data to grab. This option should
> always be used by the viewer to avoid both this kind of deadlock, but
> also to avoid hangs when the core is very busy - don't forget that the
> user program might be doing some very intense stuff in between
> plotting commands.
>
> Phil

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Is it time to remove some IPC cruft from our wxwidgets-related code?

[Phil Rosenberg]

>
> It is good that you are doing some critical thinking about my bytes
> transmission logic this way.  However, it appears you are referring to
> the case where there are two separate but simultaneous uses of IPC
> (one to send an array of data from core to viewer and one to send an
> array of data from viewer to core).

Hi Alan
Actually I am talking about the opposite case. Both core and viewer
make a receive request. In both cases the receiveBytes function will
not return until the data is received, but the other party can never
send it because it is also sat in the receiveBytes function.

Here what happens is the core sends a locate command and calls
receiveBytes waiting for a response.

The viewer receives the locate command and flags this so that we
capture the next mouse click, however before that happens the timer
triggers the viewer to check for some more data, it calls receiveBytes
then sits waiting for data. But of course the core won't send any data
until it has received the locate data.

The result is deadlock and the viewer hangs.

The proper fix should be that there is an option in receiveBytes to
return immediately if there is no data to grab. This option should
always be used by the viewer to avoid both this kind of deadlock, but
also to avoid hangs when the core is very busy - don't forget that the
user program might be doing some very intense stuff in between
plotting commands.

Phil

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Is it time to remove some IPC cruft from our wxwidgets-related code?

[Alan W. Irwin]

On 2017-10-03 00:35+0100 Phil Rosenberg wrote:


Alan
I have made a quick couple of changes that makes locate work correctly
again with wxWidgets by simply halting checking for new data while
doing a locate, then starting again when locate is complete.

However I don't want to commit anything that may clash with any
changes that you are making. Let me know if you have started making
any changes in wxplframe in the wxPLViewer and if so I'll just send
you a patch to avoid any clashes.


Hi Phil:

It is good that you think you have solved these locate issues (blank
display for both non-IPC3 (when PL_WXWIDGETS_IPC3 not #defined) and
IPC3 (when PL_WXWIDGETS_IPC3 #defined) code and no response to blind
mouse clicks for the IPC3 case).  I am not making any wxwidgets
changes at the moment because I had no idea how to solve these locate
issues and anything else I might do (getting keyboard key clicks to
work and code cleanup to get rid of non-IPC3 code) obviously should
come after these locate issues with display and mouse clicks are
solved.  So please go ahead and push your commit(s), and I will test
them on my Linux platform.

Alan

__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Is it time to remove some IPC cruft from our wxwidgets-related code?

[Alan W. Irwin]

On 2017-10-02 21:22+0100 Phil Rosenberg wrote:


Hi Alan
I literally just logged onto my email to say stop whatever you are
doing on this the locate mode is broken!!! :-D


Clearly, great minds think alike.  :-)  So indeed I plan
to retain the old IPC code for quite a bit longer (likely
to the start of the next release cycle in early 2018).



I think there may be a couple of different issues here. One is that
the viewer is checking for more data being sent and the core code is
waiting for the location information so we have a form of deadlock.


It is good that you are doing some critical thinking about my bytes
transmission logic this way.  However, it appears you are referring to
the case where there are two separate but simultaneous uses of IPC
(one to send an array of data from core to viewer and one to send an
array of data from viewer to core).  But that simultanously use case
should be handled properly now.  Here is why. The TransmitSemaphore
(i.e., the m_tsem semaphore) is used to insure that the shared memory
can only be used to transmit one (possibly large) array of bytes at
any given time.  Any attempt to try sending a second array while a
first one is being transmitted just quietly pauses (see the early call
to m_threeSemaphores.waitTransmitSemaphore() in
PLMemoryMap::transmitBytes) until just before the return from the
first complete array transmission (see the late call to
m_threeSemaphores.postTransmitSemaphore() in
PLMemoryMap::transmitBytes).  Furthermore, once
PLMemoryMap::transmitBytes on the transmitting side in tandem with
PLMemoryMap::receiveBytes on the receiving side is allowed to actually
send data by the TransmitSemaphore, they use the ReadSemaphore and the
WriteSemaphore to make sure the entire transmission of all bytes in
the array via the (possibly smaller) shared memory area is completed
without deadlocks possible.  However, if you can come up with a
specific example where this logic could deadlock, more power to you,
but instead of introducing timed waits, I would prefer to fix it if
the deadlock is a bug in the implementation of the above design or
else redesign the above protocol for the transmission of an array of
bytes if that design is not correct.


The receiveBytes functions needs a timeout otherwise it will hang the
viewer if there is a problem at the other end.


Possibly.  With the new IPC3 approach I was admittedly on a mission to
eliminate as many timed waits as possible just to see if I could
reduce that number to zero.  As a result, if the users kills the core
with ctrl-C, the wxPLViewer continues and has to be independently
killed.  And the core hangs indefinitely in debug mode without a
timeout until the user does the correct suggested invocation of
wxPLViewer.  But in my opinion these issues are simply
convenience ones that we should deal with later after everything
(e.g., locate mode) works properly with the new IPC approach.


Also with the 3sem
method it probably makes no sense to keep checking for data once we
have received a locate request. This is set by the m_locateMode
variable.


OK.


I also noticed that you have #ifdefed out the keypress code. Please
don't remove this as it will need reinstating with the new method.


I agree that should be implemented once the mouse click part of it
(which is not #ifdefed out) works.  So as stated above I plan to
retain the old IPC code to act as a guide for the new IPC code for a
while longer.

In sum, I am hoping you indeed take this opportunity to look
critically at transmitBytes and receiveBytes with the aid of my
explanation to make sure you are satisfied they should "just work". Of
course, if you can imagine a scenario where they won't work (i.e.,
there could be a deadlock issue) I will fix them. However, my current
feeling is the real issue is not the details of how those routines are
implemented, but instead some other issue in the way that locate mode
is set up on the core side and/or viewer side for the new IPC method.
For example, a detailed comparison of what happens in locate mode for
the old IPC method versus the new one might reveal some critical
logical difference between the two code paths?  But I have looked at
all of that and could not find anything wrong so I hope your fresh set
of eyes, your much larger knowledge of exactly what triggers rendering
on the viewer side (which I have never understood and which does not
currently work properly for either IPC method), and/or your different
debugging methods will help spot and fix whatever the issue might be.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the 

Re: [Plplot-devel] Is it time to remove some IPC cruft from our wxwidgets-related code?

[Phil Rosenberg]

Alan
I have made a quick couple of changes that makes locate work correctly
again with wxWidgets by simply halting checking for new data while
doing a locate, then starting again when locate is complete.

However I don't want to commit anything that may clash with any
changes that you are making. Let me know if you have started making
any changes in wxplframe in the wxPLViewer and if so I'll just send
you a patch to avoid any clashes.

I had a quick skim through the 3sem code, but you might be the best
person to add a timeout to that code.

Phil

On 2 October 2017 at 21:22, Phil Rosenberg  wrote:
> Hi Alan
> I literally just logged onto my email to say stop whatever you are
> doing on this the locate mode is broken!!! :-D
>
> I think there may be a couple of different issues here. One is that
> the viewer is checking for more data being sent and the core code is
> waiting for the location information so we have a form of deadlock.
> The receiveBytes functions needs a timeout otherwise it will hang the
> viewer if there is a problem at the other end. Also with the 3sem
> method it probably makes no sense to keep checking for data once we
> have received a locate request. This is set by the m_locateMode
> variable.
>
> I also noticed that you have #ifdefed out the keypress code. Please
> don't remove this as it will need reinstating with the new method.
>
> Phil
>
> On 2 October 2017 at 19:29, Alan W. Irwin  wrote:
>> On 2017-10-02 08:02+0100 p.d.rosenb...@gmail.com wrote:
>>
>>> Hi Alan
>>
>>
>>> I haven't really en through that code, but yes I have been using t
>>
>> and yes I'm happy for that cleanup to occur. The joy of git is that
>> the code history is still here if needed.
>>
>>> So yes, feel free to clean up as you wish.
>>
>>
>> Well, I did one last check, and it turns out I got ahead of myself in
>> making this request, but I do appreciate the keeness you share with me
>> to get this code cleaned up as soon as warranted.  But that time has
>> not (quite) arrived yet.
>>
>> The issue I spotted that currently (for the current HEAD of master)
>> has critically different results for -DPL_WXWIDGETS_IPC3=ON versus OFF
>> is -locate mode for example 1.
>>
>> If you run
>>
>> examples/c/x01c -dev wxwidgets -locate
>>
>> on Linux you get a blank screen with both the above configurations
>> which is a bug for both configurations.  But now that I have looked
>> further, if you click blindly on the location of one of the 4
>> subpages, you get some cursor position information printed to stdout
>> for the -DPL_WXWIDGETS_IPC3=OFF case and eventually the screen is
>> actually displayed for that case.  In contrast for
>> -DPL_WXWIDGETS_IPC3=ON there is no response to mouse clicks for a
>> cursor position I know is in the right place, and therefore the
>> code is apparently in an infinite loop which never displays
>> anything other than a blank screen.
>>
>> Could you take a look at the above screen display issue, and also at
>> why there is no response to mouse clicks in locate mode for just the
>> -DPL_WXWIDGETS_IPC3=ON case?
>>
>> To familiarize yourself with how locate mode should work for this
>> example, you should try other interactive devices as well.  For example,
>>
>> examples/c/x01c -dev wingcc -locate
>>
>> and/or
>>
>> examples/c/x01c -dev wingdi -locate
>>
>> should give good locate mode results (which is that if the mouse [or
>> some keyboard key if the driver supports keyboard clicking] is
>> clicked when the cursor corresponds to one of the 4 viewports, the
>> cursor position and other information is dumped to stdout; and if the
>> mouse [or keyboard key] is clicked when the cursor corresponds to a location
>> outside one
>> of the 4 viewports, locate mode terminates, and then hitting the enter
>> key will terminate the example.)  I just checked, and the
>> old wxwidgets device you can still get access to using
>> -DOLD_WXWIDGETS=ON still builds and
>>
>> examples/c/x01c -dev wxwidgets -locate
>>
>> gives the good locate mode results (both with mouse clicks and
>> keyboard key clicks) described above.
>>
>> [out of order]:
>>>
>>> One question i did have though – I remember my code being set up
>>
>> like a ring buffer, and you saying yours wasn't. But I presume it can
>> still cope with large transfers bigger than the shared memory block?
>>
>> Yes, transferring large blocks of bytes in either direction is what
>> two of the three semaphores control.  This works without any timed
>> waits at all.  (The other semaphore controls use of the entire
>> transfer method similar to your mutex).  My speed tests showed that
>> method of transferring bytes stopped being significantly dependent on
>> shared memory buffer size as soon as that shared memory size (+ a
>> small overhead) was 1KB or greater.  So to be absolutely safe
>> concerning efficiency I set it to 10KB (+ a small overhead).  See the
>> note concerning PL_SHARED_ARRAY_SIZE in 

Re: [Plplot-devel] Is it time to remove some IPC cruft from our wxwidgets-related code?

[Phil Rosenberg]

Hi Alan
I literally just logged onto my email to say stop whatever you are
doing on this the locate mode is broken!!! :-D

I think there may be a couple of different issues here. One is that
the viewer is checking for more data being sent and the core code is
waiting for the location information so we have a form of deadlock.
The receiveBytes functions needs a timeout otherwise it will hang the
viewer if there is a problem at the other end. Also with the 3sem
method it probably makes no sense to keep checking for data once we
have received a locate request. This is set by the m_locateMode
variable.

I also noticed that you have #ifdefed out the keypress code. Please
don't remove this as it will need reinstating with the new method.

Phil

On 2 October 2017 at 19:29, Alan W. Irwin  wrote:
> On 2017-10-02 08:02+0100 p.d.rosenb...@gmail.com wrote:
>
>> Hi Alan
>
>
>> I haven't really en through that code, but yes I have been using t
>
> and yes I'm happy for that cleanup to occur. The joy of git is that
> the code history is still here if needed.
>
>> So yes, feel free to clean up as you wish.
>
>
> Well, I did one last check, and it turns out I got ahead of myself in
> making this request, but I do appreciate the keeness you share with me
> to get this code cleaned up as soon as warranted.  But that time has
> not (quite) arrived yet.
>
> The issue I spotted that currently (for the current HEAD of master)
> has critically different results for -DPL_WXWIDGETS_IPC3=ON versus OFF
> is -locate mode for example 1.
>
> If you run
>
> examples/c/x01c -dev wxwidgets -locate
>
> on Linux you get a blank screen with both the above configurations
> which is a bug for both configurations.  But now that I have looked
> further, if you click blindly on the location of one of the 4
> subpages, you get some cursor position information printed to stdout
> for the -DPL_WXWIDGETS_IPC3=OFF case and eventually the screen is
> actually displayed for that case.  In contrast for
> -DPL_WXWIDGETS_IPC3=ON there is no response to mouse clicks for a
> cursor position I know is in the right place, and therefore the
> code is apparently in an infinite loop which never displays
> anything other than a blank screen.
>
> Could you take a look at the above screen display issue, and also at
> why there is no response to mouse clicks in locate mode for just the
> -DPL_WXWIDGETS_IPC3=ON case?
>
> To familiarize yourself with how locate mode should work for this
> example, you should try other interactive devices as well.  For example,
>
> examples/c/x01c -dev wingcc -locate
>
> and/or
>
> examples/c/x01c -dev wingdi -locate
>
> should give good locate mode results (which is that if the mouse [or
> some keyboard key if the driver supports keyboard clicking] is
> clicked when the cursor corresponds to one of the 4 viewports, the
> cursor position and other information is dumped to stdout; and if the
> mouse [or keyboard key] is clicked when the cursor corresponds to a location
> outside one
> of the 4 viewports, locate mode terminates, and then hitting the enter
> key will terminate the example.)  I just checked, and the
> old wxwidgets device you can still get access to using
> -DOLD_WXWIDGETS=ON still builds and
>
> examples/c/x01c -dev wxwidgets -locate
>
> gives the good locate mode results (both with mouse clicks and
> keyboard key clicks) described above.
>
> [out of order]:
>>
>> One question i did have though – I remember my code being set up
>
> like a ring buffer, and you saying yours wasn't. But I presume it can
> still cope with large transfers bigger than the shared memory block?
>
> Yes, transferring large blocks of bytes in either direction is what
> two of the three semaphores control.  This works without any timed
> waits at all.  (The other semaphore controls use of the entire
> transfer method similar to your mutex).  My speed tests showed that
> method of transferring bytes stopped being significantly dependent on
> shared memory buffer size as soon as that shared memory size (+ a
> small overhead) was 1KB or greater.  So to be absolutely safe
> concerning efficiency I set it to 10KB (+ a small overhead).  See the
> note concerning PL_SHARED_ARRAY_SIZE in drivers/wxwidgets_comms.h.
> That value is significantly smaller than the ring buffer size which is
> set to 1024K (in drivers/wxwidgets_dev.cpp) for the case when
> PL_WXWIDGETS_IPC3 is not #defined.
>
>
> Alan
> __
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project 

Re: [Plplot-devel] Is it time to remove some IPC cruft from our wxwidgets-related code?

[Alan W. Irwin]

On 2017-10-02 08:02+0100 p.d.rosenb...@gmail.com wrote:


Hi Alan



I haven't really en through that code, but yes I have been using t

and yes I'm happy for that cleanup to occur. The joy of git is that
the code history is still here if needed.


So yes, feel free to clean up as you wish.


Well, I did one last check, and it turns out I got ahead of myself in
making this request, but I do appreciate the keeness you share with me
to get this code cleaned up as soon as warranted.  But that time has
not (quite) arrived yet.

The issue I spotted that currently (for the current HEAD of master)
has critically different results for -DPL_WXWIDGETS_IPC3=ON versus OFF
is -locate mode for example 1.

If you run

examples/c/x01c -dev wxwidgets -locate

on Linux you get a blank screen with both the above configurations
which is a bug for both configurations.  But now that I have looked
further, if you click blindly on the location of one of the 4
subpages, you get some cursor position information printed to stdout
for the -DPL_WXWIDGETS_IPC3=OFF case and eventually the screen is
actually displayed for that case.  In contrast for
-DPL_WXWIDGETS_IPC3=ON there is no response to mouse clicks for a
cursor position I know is in the right place, and therefore the
code is apparently in an infinite loop which never displays
anything other than a blank screen.

Could you take a look at the above screen display issue, and also at
why there is no response to mouse clicks in locate mode for just the
-DPL_WXWIDGETS_IPC3=ON case?

To familiarize yourself with how locate mode should work for this
example, you should try other interactive devices as well.  For example,

examples/c/x01c -dev wingcc -locate

and/or

examples/c/x01c -dev wingdi -locate

should give good locate mode results (which is that if the mouse [or
some keyboard key if the driver supports keyboard clicking] is
clicked when the cursor corresponds to one of the 4 viewports, the
cursor position and other information is dumped to stdout; and if the
mouse [or keyboard key] is clicked when the cursor corresponds to a location 
outside one
of the 4 viewports, locate mode terminates, and then hitting the enter
key will terminate the example.)  I just checked, and the
old wxwidgets device you can still get access to using
-DOLD_WXWIDGETS=ON still builds and

examples/c/x01c -dev wxwidgets -locate

gives the good locate mode results (both with mouse clicks and
keyboard key clicks) described above.

[out of order]:

One question i did have though – I remember my code being set up

like a ring buffer, and you saying yours wasn't. But I presume it can
still cope with large transfers bigger than the shared memory block?

Yes, transferring large blocks of bytes in either direction is what
two of the three semaphores control.  This works without any timed
waits at all.  (The other semaphore controls use of the entire
transfer method similar to your mutex).  My speed tests showed that
method of transferring bytes stopped being significantly dependent on
shared memory buffer size as soon as that shared memory size (+ a
small overhead) was 1KB or greater.  So to be absolutely safe
concerning efficiency I set it to 10KB (+ a small overhead).  See the
note concerning PL_SHARED_ARRAY_SIZE in drivers/wxwidgets_comms.h.
That value is significantly smaller than the ring buffer size which is
set to 1024K (in drivers/wxwidgets_dev.cpp) for the case when
PL_WXWIDGETS_IPC3 is not #defined.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Re: [Plplot-devel] Is it time to remove some IPC cruft from our wxwidgets-related code?

[p.d.rosenberg]

Hi Alan
I haven't really en through that code, but yes I have been using t and yes I'm 
happy for that cleanup to occur. The joy of git is that the code history is 
still here if needed.

One question i did have though – I remember my code being set up like a ring 
buffer, and you saying yours wasn't. But I presume it can still cope with large 
transfers bigger than the shared memory block?

So yes, feel free to clean up as you wish.

Phil

Sent from my Windows 10 phone

From: Alan W. Irwin
Sent: 02 October 2017 06:25
To: Phil Rosenberg; PLplot development list
Subject: Is it time to remove some IPC cruft from our wxwidgets-related code?

Hi Phil:

Thanks for all the testing and bug-fixing for wxwidgets that you have
being charging through this weekend.

During the course of that testing (presumably on Windows) I am going
to assume you just used the default given by

option(PL_WXWIDGETS_IPC3 "Use the three-semaphores approach for wxwidgets IPC" 
ON)

(i.e., you did not specifically use -DPL_WXWIDGETS_IPC3=OFF). That
default case corresponding to -DPL_WXWIDGETS_IPC3=ON is what I
constantly use on Linux for wxwidgets, and I am happy with it.

Are you happy with your recent experience with the three-semaphores
IPC approach on Windows, i.e., has everything worked as well as with the old
IPC approach with no noticeable slowdowns?  If so and whenever you give
the OK, I propose to remove from our wxwidgets-related code your
original IPC approach which involved a circular buffer code and a
mutex, i.e., all code which is currently compiled only if the
PL_WXWIDGETS_IPC3 macro is NOT #defined.  That change should make both
the -dev wxwidgets code and wxPLViewer code much easier to understand
which is why I am pushing for this change.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

[Plplot-devel] Is it time to remove some IPC cruft from our wxwidgets-related code?

[Alan W. Irwin]

Hi Phil:

Thanks for all the testing and bug-fixing for wxwidgets that you have
being charging through this weekend.

During the course of that testing (presumably on Windows) I am going
to assume you just used the default given by

option(PL_WXWIDGETS_IPC3 "Use the three-semaphores approach for wxwidgets IPC" 
ON)

(i.e., you did not specifically use -DPL_WXWIDGETS_IPC3=OFF). That
default case corresponding to -DPL_WXWIDGETS_IPC3=ON is what I
constantly use on Linux for wxwidgets, and I am happy with it.

Are you happy with your recent experience with the three-semaphores
IPC approach on Windows, i.e., has everything worked as well as with the old
IPC approach with no noticeable slowdowns?  If so and whenever you give
the OK, I propose to remove from our wxwidgets-related code your
original IPC approach which involved a circular buffer code and a
mutex, i.e., all code which is currently compiled only if the
PL_WXWIDGETS_IPC3 macro is NOT #defined.  That change should make both
the -dev wxwidgets code and wxPLViewer code much easier to understand
which is why I am pushing for this change.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel