On Mar 19, 2015, at 4:03 PM, Andrew Ross <andrewr...@users.sourceforge.net> wrote:
> On Thu, Mar 19, 2015 at 03:30:21PM -0400, Hazen Babcock wrote: >>> From: Andrew Ross <andrewr...@users.sourceforge.net> >>> >>>> The attached patch fixes the memory leak for me. Pressing the close button >>>> should now behave the same as pressing 'Q', i.e. it will abort the >>>> program and clean up correctly. It looks like this was changed at some >>>> stage in the past, but I don't know why. I guess this would allow a >>>> programme to continue, and to potentially reopen a new xwin window. If we >>>> want to retain this functionality it will require a bit more thinking >>>> about. >>> >>> Thinking some more about this, I seem to recall the change was made >>> because of interactive bindings. For example, if you are using octave and >>> pressed the close button then the call to plabort would kill your entire >>> octave session which is clearly not desirable. We definitely don't want to >>> apply my patch as is. I need to work through all the tidy up code in >>> xwin.c to check exactly the path that is being followed. The current code >>> is doing the right thing in terms of closing the window and ignoring all >>> further commands to the plplot stream, we just need to ensure that the >>> tidy function is called at the end. A clean way of doing this would be to >>> have multiple levels of stream_closed. 0 = open, 1 = closed, but still >>> need to call tidy, 2 = closed and tidy already called. >>> >>> Only the xwin and cairo drivers set this flag, but it is checked in the >>> core plplot code. I can simply implement this change Alan, but your call >>> whether you want to commit it at this late stage. It should be trivial. >> >> Yes, it was implemented for exactly the reason that you state. I added >> this in September of 2010 (v11159, v11160). I'd appreciate if we did not >> revert to the old behavior which was, in my opinion, very unfriendly. > > I agree Hazen. My fix (which I'll wait until post-release to apply) > doesn't revert to calling plabort. > > This strikes me as another reason why we need to bite the bullet and tidy > up our error handling in plplot. We really need to get rid of plabort() and > all the calls to exit(). Libraries shouldn't exit - they should return an > error and let the calling program make the decision. > > We've known this for a long time, but it will be a pretty intrusive (and > backwards incompatible) change to plplot. Maybe I should just take this on > post-release if others are in agreement. > I was planning on cleaning up error and warning handling post-release. While working on plbuf and metafiles, I kept grappling with how to best handle errors and warnings. ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
