Menu
▾
▴
plplot-devel
|
From: Alan W. I. <ir...@be...> - 2002-12-10 08:08:34
|
Apparently Joao has sequences of plinit, plend, plinit in his "x" octave examples which violated an assumption I had made that a call to plend was the last possible use of libplplot in a programme. With that assumption I could release libltdl memory resources in plend. I have now fixed this so the libtldl memory resources are never released. Now on my system all of Joao's "x" examples run and all his "p" examples also run except for p7 and p15. Apparently Joao knows what the p7 trouble is so that leaves only p15 as the last octave example where there is unexplained trouble. This is a nice step forward, but nevertheless, I am now having second thoughts about this "fix" because I like the idea of plend being the last possible call to the libplplot library so we could release all dynamic driver (and in my case the libltdl) memory resources there. Those are the memory resources that are allocated when the library is initialized so this is the only possible place to release the resources again. But that cannot be done if our users are free to call plinit again after plend is called. I would like to hear the developer's thoughts (especially Joao's thoughts) on this topic. For example, there should be a way for the octave x examples to work using pladv without having to call any libplplot function after plend is called at the very end of the x plots. I assert that because all the normal x examples in C are done that way so I assume octave can follow that model. Alternatively, there is the python or tcl model where plinit is called once before all examples are plotted, every example restores initial values (colour maps) when its part of the plotting is done, and plend is called once at the end (see xw??.py and pythondemos.tcl to see how this approach all fits together). Could that "python" approach work for octave, Joao? Alan email: ir...@be... phone: 250-727-2902 FAX: 250-721-7715 snail-mail: Dr. Alan W. Irwin Department of Physics and Astronomy, University of Victoria, P.O. Box 3055, Victoria, British Columbia, Canada, V8W 3P6 __________________________ Linux-powered astrophysics __________________________ |
|
From: Maurice L. <mj...@ga...> - 2002-12-10 08:54:29
|
I can't tell you the specific answer to your questions due to how maniacally busy I am these days (having just joined Lightspeed Semiconductor), but I can elucidate some of the plplot design ideas that have historically been un-documented. And, I can give it in an object-oriented context, which (because it is "canonical") is a lot nicer than the "this is the way it should work" approach I've used historically. :) This also includes proposals for change to how we do it now -- i.e. the behavior of plinit(). I've always been somewhat bothered by the way stream 0 vs stream N is handled (this bugged me back in '94 but I wasn't exactly swimming in free time then either). When plplot starts, you have the statically pre-allocated stream, stream 0. Yes the stream 0 that I hate b/c it's not allocated on the heap like a proper data-structure/object (in the plframe widget I automatically start from stream 1). So stream 0 is like a class definition and an instance rolled into one. What I think we need to do is get rid of the "instance" part of this and leave stream 0 as a "class definition" only. In this case all the command line arguments and initial pls...() calls (before plinit) serve to override the default initializion of the class variables, i.e. set stream 0 parameters only In other words, stream 0 becomes the template for all plplot streams. You can use it, but once you've called plinit() you have your own "instance" of the plplot "object" -- i.e. you have a new stream with all the relevant state info copied from stream 0. If you change it, it dies when your stream dies with plend1(). If you really want to change stream 0 (i.e. the "plplot object" "class data") you can always set your stream number to 0 and fire away. To summarize: plinit() creates a new stream, copied from stream 0 plend1() deletes that stream plend() deletes all streams, except of course stream 0 which is "class data" Let me know if any of this helps. -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
|
From: Maurice L. <mj...@ga...> - 2002-12-10 09:09:12
|
Maurice LeBrun writes: > This also includes proposals for change to how we do it now -- i.e. the > behavior of plinit(). I've always been somewhat bothered by the way stream 0 > vs stream N is handled (this bugged me back in '94 but I wasn't exactly > swimming in free time then either). BTW just offhand the only things needed to implement this fully-consistent model for library & initialization are: - modify plinit() to call plmkstrm() and plcpstrm() (example in plframe.c) - plend() doesn't touch either global data or stream 0 "class data" (leave that for the OS) Should be pretty easy. -- Maurice LeBrun mj...@ga... Research Organization for Information Science and Technology of Japan (RIST) |
|
From: Joao C. <jc...@fe...> - 2002-12-10 11:00:45
|
On Tuesday 10 December 2002 08:07, Alan W. Irwin wrote: > Apparently Joao has sequences of plinit, plend, plinit in his "x" octav= e > examples which violated an assumption I had made that a call to plend w= as > the last possible use of libplplot in a programme. With that assumptio= n I > could release libltdl memory resources in plend. I have now fixed this= so > the libtldl memory resources are never released. Now on my system all = of > Joao's "x" examples run and all his "p" examples also run except for p7= and > p15. Apparently Joao knows what the p7 trouble is so that leaves only p= 15 > as the last octave example where there is unexplained trouble. > > This is a nice step forward, but nevertheless, I am now having second > thoughts about this "fix" because I like the idea of plend being the la= st > possible call to the libplplot library so we could release all dynamic > driver (and in my case the libltdl) memory resources there. Those are = the > memory resources that are allocated when the library is initialized so = this > is the only possible place to release the resources again. But that ca= nnot > be done if our users are free to call plinit again after plend is calle= d. > > I would like to hear the developer's thoughts (especially Joao's though= ts) > on this topic. For example, there should be a way for the octave x exam= ples > to work using pladv without having to call any libplplot function after > plend is called at the very end of the x plots. I assert that because = all > the normal x examples in C are done that way so I assume octave can fol= low > that model. That is not the problem. The problem is an user program finish doing a pl= ot,=20 and thus closing the plot using plend(). Latter on, in the same program,=20 another plot is needed, thus plinit() is again called. The x??c examples all finish with plend(), thus the octave counterparts a= lso=20 do the same. But *one* instance of Octave wants to run *all* x??c demos, = thus=20 the several plinit/plend. I often do that in Octave, closing a plot figure, opening another, ... an= d all=20 users of interactive languages certainly do the same. Of course, I could = use=20 plinit/plend1(), but then, when would I call plend()? I really never know= =20 when the user has finished opening/closing plot windows or finished using= =20 Octave (*). I never bother releasing memory that will be relased anyway by the OS whe= n a=20 program finish. At least in unix, when a program finish, the memory owned= by=20 the program will be released. Joao (*)- I could register with atexit() a function that would do the cleanup,= but=20 what for? The OS does it for me. > Alternatively, there is the python or tcl model where plinit is > called once before all examples are plotted, every example restores ini= tial > values (colour maps) when its part of the plotting is done, and plend i= s > called once at the end (see xw??.py and pythondemos.tcl to see how this > approach all fits together). Could that "python" approach work for oct= ave, > Joao? > > Alan > > email: ir...@be... > phone: 250-727-2902=09FAX: 250-721-7715 > snail-mail: > Dr. Alan W. Irwin > Department of Physics and Astronomy, > University of Victoria, P.O. Box 3055, > Victoria, British Columbia, Canada, V8W 3P6 > __________________________ > > Linux-powered astrophysics > __________________________ > > > > ------------------------------------------------------- > 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 |
|
From: Alan W. I. <ir...@be...> - 2002-12-10 16:44:43
|
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 program, > another plot is needed, thus plinit() is again called. > The x??c examples all finish with plend(), thus the octave counterparts 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, ... and all > users of interactive languages certainly do the same. Of course, 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 plend1 and never called plend)? I assumed it would even with default stream 0, but you introduced the interesting topic of stream 0 class versus stream >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. So if you killed the programme rather than normally exiting, you never got the memory back. I had first-hand experience of this many times in the first half of the 90's and the only recourse was to reboot the system to get all the memory back if newbie users were making the mistake 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 know 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 plend, then the user can simply use this sequence when it is impossible to predict when the last plot will occur. Then, plend could be strictly reserved for situations where you *know* this is the last plot before exit if you care about cleaning up memory use and not relying on the OS to do it for you. (I believe this was the original intent from the way it is documented, see http://plplot.sourceforge.net/resources/docbook-manual/plplotdoc-html-0.4.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 of a burden, we also have the option of adding another function (pllibfree?) to our API to systematically free all the memory that was allocated when the library was opened. 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 |
|
From: Joao C. <jc...@fe...> - 2002-12-10 19:32:50
|
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 |
|
From: Alan W. I. <ir...@be...> - 2002-12-10 21:43:40
|
On Tue, 10 Dec 2002, Joao Cardoso wrote: > > 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 > that case the shared memory will stay (usable by other processes) in the > system, even when the program who allocate it exits. It must be explicitly > released. I was probably talking about shared memory.....(with my further questions about this carried on privately). > > 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 of 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 > that plinit/plend1 will be fine. Good. > Also, our library does not has a specific entry point to initialize it, and > thus it doesn't make much sense to have one to finish using it. Maurice set this up some time ago. It has not been well advertised so I will mention the details again. plinit (which every initialization of plplot must go through) calls pllib_init. The first call to pllib_init initializes the library including memory for the dynamic driver infrastructure as well as the memory for libltdl. Thus, it makes sense to have a function (the very last call to libplplot) which releases the memory that was allocated as part of the library initialization > This is a difficult problem to solve, releasing all allocated memory. For > example, when one use strdup(), or our plstrdup() version, we might lost the > track of the allocated memory -- that's why valgrind reports "definitively > lost fragments" Yes, you would have to be careful. But a start is to at least release the libltdl memory which is easy to do. So has a consensus been reached here to use plend for this library memory release task with appropriate plend =>plend1 adjustments to the x octave scripts? Alan |
|
From: Joao C. <jc...@fe...> - 2002-12-11 00:45:20
|
On Tuesday 10 December 2002 21:42, Alan W. Irwin wrote: > On Tue, 10 Dec 2002, Joao Cardoso wrote: =2E.. > > Also, our library does not has a specific entry point to initialize i= t, > > and thus it doesn't make much sense to have one to finish using it. > > Maurice set this up some time ago. It has not been well advertised so = I > will mention the details again. plinit (which every initialization of > plplot must go through) calls pllib_init. The first call to pllib_init > initializes the library including memory for the dynamic driver > infrastructure as well as the memory for libltdl. Thus, it makes sense= to > have a function (the very last call to libplplot) which releases the me= mory > that was allocated as part of the library initialization In that case, a pllib_end() makes sense! Symmetry is something I like (I'= m a=20 physicist...). =46rom your description, pllib_end should release the memory allocated by= =20 pllib_init. And plend should call pllib_end, as plinit calls pllib_init. = =20 > > This is a difficult problem to solve, releasing all allocated memory.= For > > example, when one use strdup(), or our plstrdup() version, we might l= ost > > the track of the allocated memory -- that's why valgrind reports > > "definitively lost fragments" > > Yes, you would have to be careful. But a start is to at least release > the libltdl memory which is easy to do. Sure. knowing that a pllib_end() exists will encourage us to not loose th= e=20 track of allocated memory. > So has a consensus been reached here to use plend for this library memo= ry > release task with appropriate plend =3D>plend1 adjustments to the x oct= ave > scripts? OK. But don't you want to accept my idea of a pllib_end()? I will only commit my changes after AT stabilizes. Joao > > Alan |
|
From: Alan W. I. <ir...@be...> - 2002-12-11 17:21:23
|
On Wed, 11 Dec 2002, Joao Cardoso wrote: > In that case, a pllib_end() makes sense! Symmetry is something I like (I'm a > physicist...). > >From your description, pllib_end should release the memory allocated by > pllib_init. And plend should call pllib_end, as plinit calls pllib_init. > > Sure. knowing that a pllib_end() exists will encourage us to not loose the > track of allocated memory. > > > So has a consensus been reached here to use plend for this library memory > > release task with appropriate plend =>plend1 adjustments to the x octave > > scripts? > > OK. But don't you want to accept my idea of a pllib_end()? That sounds fine to me. For now, I have reactivated what I did to release libltdl memory in plend, and changed your octave x examples (plend ==> plend1) so they still work. I encourage you to follow up on that with implementing the pllib_end idea. I prefer you to do that aspect since I always seem to have trouble creating new C functions correctly. Also, you will probably want to set a flag in pllib_end so that any attempt to call plinit afterward fails gracefully rather than just crashing because the memory resources are gone. Obviously, this is just the start of pllib_end. I encourage those who are familiar with the dynamic driver's memory allocation to release it properly in pllib_end to respond to the bug report that Joao mentioned in a later e-mail as well as to get a clean bill of health from valgrind. Alan email: ir...@be... phone: 250-727-2902 FAX: 250-721-7715 snail-mail: Dr. Alan W. Irwin Department of Physics and Astronomy, University of Victoria, P.O. Box 3055, Victoria, British Columbia, Canada, V8W 3P6 __________________________ Linux-powered astrophysics __________________________ |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X