Re: [Plplot-devel] plinit, plend, plinit sequence now works, but I am having second thoughts

[Joao C. <jc...@fe...>]

On Tuesday 10 December 2002 16:43, Alan W. Irwin wrote:
> On Tue, 10 Dec 2002, Joao Cardoso wrote:
> > [...]The problem is an user program finish doing a plot,
> > and thus closing the plot using plend(). Latter on, in the same progr=
am,
> > another plot is needed, thus plinit() is again called.
> > The x??c examples all finish with plend(), thus the octave counterpar=
ts
> > also do the same. But *one* instance of Octave wants to run *all* x??=
c
> > demos, thus the several plinit/plend.
> >
> > I often do that in Octave, closing a plot figure, opening another, ..=
=2E
> > and all users of interactive languages certainly do the same. Of cour=
se,
> > I could use plinit/plend1(),
>
> I woke up this morning with this same idea.
>
> Maurice, would that work (if the interactive user always stuck with ple=
nd1
> and never called plend)?

Actually, if the Octave users use the script functions in plplot_octave, =
i.e.,=20
if they use figure() to open a new plot window and closefigure() to close=
 it,=20
then they will be using plinit/plend1. Only if they call closeallfig() th=
en=20
plend() will be called.
And, yet, when figure() is called, I register closeallfig() with atexit()=
,=20
thus efectively calling plend() when Octave exits!
Thus I have done it right from the beginning, back in 98.

The x??c issue is different, as I wanted to mimic the most exactly possib=
le=20
the c examples. I can replace plend with plend1 without problems. What ot=
hers=20
front-ends do when emulating x??c?

>  I assumed it would even with default stream 0,
> but you introduced the interesting topic of stream 0 class versus strea=
m >0
> instance, and now I don't know whether that is a separate issue or
> not....;-)
>
> > I never bother releasing memory that will be relased anyway by the OS
> > when a program finish. At least in unix, when a program finish, the
> > memory owned by the program will be released.
>
> Actually, with sunos, memory had to be specifically released by the
> programme.

Hard to believe! sunos is unix. Unless you are talking of shared memory, =
as in=20
that case the shared memory will stay (usable by other processes) in the=20
system, even when the program who allocate it exits. It must be explicitl=
y=20
released.

> So if you killed the programme rather than normally exiting, you
> never got the memory back.  I had first-hand experience of this many ti=
mes
> in the first half of the 90's

I used shared memory back in 89/91, first in xenix, then on sco-unix. Whe=
n I=20
worked in embedded system, I had to implement malloc/free from scratch,=20
functions that use sbrk(), that only extends the data segment of the prog=
ram,=20
segment which is naturally released when the program finish. This is why =
we=20
sometimes gets "segmentation violation", i.e., one is acessing memory fro=
m=20
other process segments (or the own process other segments).

But this is history, and I believe that other OSes (such as MS-ones ;-) d=
on't=20
work this way.

> and the only recourse was to reboot the
> system to get all the memory back if newbie users were making the mista=
ke
> of killing programmes rather than letting them normally exit.  Part of =
my
> prejudice against Unix (and love of Linux since it does release memory =
as
> you indicated) originates from those difficult days.  Hopefully not too
> many unices have inherited this memory misfeature from sunos.  But I kn=
ow
> of at least one of our users, who does not have the financial resources=
 to
> pay the solaris license fees, who still uses sunos!
>
> Assuming the plinit/plend1 sequence will work without ever calling plen=
d,
> then the user can simply use this sequence when it is impossible to pre=
dict
> when the last plot will occur. Then, plend could be strictly reserved f=
or
> situations where you *know* this is the last plot before exit if you ca=
re
> about cleaning up memory use and not relying on the OS to do it for you=
=2E
> (I believe this was the original intent from the way it is documented, =
see
> http://plplot.sourceforge.net/resources/docbook-manual/plplotdoc-html-0=
=2E4.1
>/plend.html).
>
> My own feeling is not too many of our users currently use the
> plinit/plend/plinit sequence so it wouldn't be too much of a burden to =
ask
> them to shift to plinit/plend1/plinit. But if this really is too much o=
f a
> burden, we also have the option of adding another function (pllibfree?)

remember to not polute the API. We should be carefull with this issue. I =
think=20
that plinit/plend1 will be fine.
Also, our library does not has a specific entry point to initialize it, a=
nd=20
thus it doesn't make much sense to have one to finish using it.

> to
> our API to systematically free all the memory that was allocated when t=
he
> library was opened.

This is a difficult problem to solve, releasing all allocated memory. For=
=20
example, when one use strdup(), or our plstrdup() version, we might lost =
the=20
track of the allocated memory -- that's why valgrind reports "definitivel=
y=20
lost fragments", or somethink like that. Also, there are leaks in system=20
libraries, when you open a file, e.g.. Not to mention other libraries lea=
ks.=20
Well, not leaks. I only call something a leak when it is continuously=20
leaking, i.e. successively allocating more and more memory.

Joao

>  I would at least like to have such a function to use
> in our non-interactive example programmes. I don't care whether that
> function is called plend or something else like pllibfree so long as we
> have it.
>
> Alan
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel