Re: [Plplot-devel] Dropping the closeQtapp call

[Alan W. I. <Ala...@gm...>]

On 2018-12-29 11:56-0000 António Rodrigues Tomé wrote:

> On Sat, Dec 29, 2018 at 11:20 AM Alan W. Irwin <Ala...@gm...>
> wrote:
>
>> On 2018-12-29 09:17-0000 António Rodrigues Tomé wrote:
>>
>>> On Sat, Dec 29, 2018 at 2:28 AM Alan W. Irwin <
>> Ala...@gm...>
>>
>>> I'm puzzled my changes do not in any way affect the extqt case. the
>> ext-qt
>>> also  should never  call
>>> closeQtapp() but in fact it  calls it but it is a flaw in code that does
>>> do not arm because as you said appCounter becomes -1 and nothing is done
>>> besides the mutex instruction that i'm still uneasy with them, otherwise
>> it
>>> would kill the program.
>>
>> Actually, this is the source of my unease with this code as well.
>> Therefore, I plan to drop that closeQtapp call from
>> plD_tidy_extqt not only to make the code cleaner but also because the
>> current code would fail if some external qt application tried to use
>> the combination of extqt with, say, pngqt (e.g., to make a permanent
>> PNG file corresponding to what was displayed on the screen using
>> extqt).
>>
>
> just put the mutex instruction   in plD_tidy_extqt;

Sorry, António, but I think this comment about the mutex means you
misunderstood my comments above.  So to explain them further, the
current situation is plD_init_extqt (rightly because all uses of extqt
create their own qApp) does not call initQtApp.  Therefore, from the
perspective of code cleanliness it makes sense to drop the closeQtapp
call from plD_tidy_extqt.  Also, for the case where some external qt
application attempted to use both extqt and some other qt device, appCounter ends
up as 0 rather than -1 causing an incorrect delete of qApp for that
case.  So to avoid this potential error it also makes sense to drop
the closeQtapp call from plD_tidy_extqt.

Further to your remark about the mutex above (and your much earlier remark
that you didn't quite understand the purpose of that mutex), I am pretty sure I
understand its use in the code now.  It does give thread safety for
multiple use of the static appCounter variable, i.e., if two different
threads were using qt devices and looking at and modifying appCounter
simultaneously.  Of course, PLplot has many instances where it is not
(yet) thread safe, but Alban didn't want to add to them with
appCounter.  So this "due diligence" on his part is the reason that

QMutexLocker locker( &QtPLDriver::mutex );

is called in the routines that read or write appCounter, namely
initQtApp and closeQtapp.  However, calling it in plD_tidy_extqt would
have no purpose since that routine doesn't access appCounter.

Anyhow, I am pretty confident of my analysis so I still plan to push the above
change later today.  However, if I missed something let me know, and
if your reply happens after the push because of time zone differences
between us, we can make further corrections after that push as well.

> The original author never considered the need of any of the others qt
> drivers from a qt application what for me is amazing...

Actually, Alban, was one of those guys that understood Qt and C++
completely.  So back in 2009 he was the right choice from the QSAS
development team to create all the Qt components of PLplot for us.
And he amazed us all by doing that 3 times or so (with an initial
write and a couple of complete rewrites in response to our questions)
in the last month or so he worked for QSAS.  So I think he did an
amazingly good job for such quick work.  However, there are obviously
still a few problems left in his code, and I am glad you are finding
those and fixing them.  For example, your font fix for our qt devices
finally made our qt devices essentially the same high quality as our
cairo devices which previously I considered to be our best set of
devices.  And our qt binding has a lot of potential as well (as you
have discovered with your own qt applications).

Alan
__________________________
Alan W. Irwin

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
__________________________