Hi Alan
> > thanks again for your comments and for the patches. As usual I already
> > worked on a fix and in fact made nearly the identical changes to the
> > code as you suggested (commited to svn just now). About the merging
> > the options - this we should discuss here on the list. I conclude now
> > everything and ask the list for comments:
>
> I am not sure whether you changed the processing of general options or not,
> but I confirm those still work as expected for a single stream.
No, the only thing I touched at this time was the processing of driver
options. The scanning of general options should be totally unaffected by my
patch.
> However, that does not seem to be the case for independent driver options
> for the two streams (specified by, e.g., plsetopt("drvopt", "text=0" for the
> second stream for device ps);) for example 14. Depending on device (I
> tried, png, pngcairo, and ps), I get segfaults, drvopt ignored, different
> results for different pages of the example, and indeed in one case (the ps
> device driver) it actually does seem to work.
>
> At this point I don't know whether these issues are due to specific driver
> implementation problems, drvopt problems for multiple streams, a combination
> of the two, or something else.
This I presume is still with my patch in place? I admit I haven't tested it
with multiple streams as yet. Off the top of my head there could be issues
with DRV_STR options since pointers to the values within the option table
are stored by the drivers concerned. If a change to an option causes a
deallocation/reallocation then this will cause issues for drivers holding a
pointer to the original allocation. The other option types shouldn't be
affected though since the value is copied to the respective driver-local
storage.
This brings up another interesting aside: should DRV_STR values be
strdup()ed when copying to driver-local storage? This would isolate drivers
from any changes made to the global option table which is probably a good
thing. Admittedly it would then be the responsibility of the driver cleanup
function to free() these but given that there are so few DRV_STR options
it's probably not a bad thing.
I haven't looked at Werner's new code, but I suspect it will cause problems
similar to the above for DRV_STR options. If you set a DRV_STR for a given
driver then a pointer to the string in the option table will be referenced
by that driver. If you then create another stream and call plsetopt() (thus
deleting the table in Werner's new code) then the first driver - which is
still active - will be left with a pointer to memory which has been freed.
Again note that this only affects DRV_STR options (of which there are
relatively few).
Regards
jonathan
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
