Hi Alan
On Tue, Feb 23, 2016 at 11:00:24AM -0800, Alan W. Irwin wrote:
> Hi Phil:
> On 2016-02-23 11:21-0000 Phil Rosenberg wrote:
>
> > Hi Alan and Jim
> > I entirely advocate this. This is the same model that libcurl uses
> > too. In libcurl the "context" variable is a typecast void* so is
> > entirely opaque to the user, but it gets cast to a structure
> > internally. I presume the idea would be that the user would use one
> > context per thread?
> >
> [...]
> > So in summary:
> >
> > Pass in a context for helping thread safety - definitely
>
> It appears everyone so far is happy with the context approach.
> Furthermore, it appears now with thread-local storage that the address of
> the context does not need to be an argument which makes life a lot
> simpler for our users.
>From my perspective as a user of plplot I think having the explicit context
argument in the C API has distinct advantages. I have written several
programs where multiple plot streams were being maintained in parallel from
a common data source. I got it working but the need to deal with a single
global plot context made this more difficult than it might otherwise have
been. Wrapping this context up into a context structure is a great first
step. However, the full benefit won't be available if this is just stored
in thread-local storage because a single thread will still be dealing with
what is essentially a global context.
I certainly understand the need to keep API changes to a minimum to avoid
inflicting undue pain on users. At the same time, while thread-local global
context storage may provide thread safety it means that people who require
multiple plot contexts could not achieve this unless they split their work
across multiple threads. The inclusion of an explicit context argument
addresses both considerations.
On a related matter, the placement of the context argument at the end of the
argument list in the original proposal was intriging. Most libraries I've
used which include such an argument include it as the first argument and
this makes more sense to my brain at least. What is the rationale for
having it at the end of the list? Does it make it easier to support earlier
API versions which lack the new argument?
While there's talk about APIs, I also encountered what seemed to be a slight
oddity in the C++ API under plplot 5.10.0. In particular there doesn't
appear to be any plstream method equivalent to plsetqtdev(). Instead one
must call plsetqtdev() which relies on the global "current stream" variable
plsc. The practical upshot is that one must ensure that no new plstream is
created between the creation of a plstream and it's companion call to
plsetqtdev(). It would be much neater and more consistent if one could just
do
plstream *pls = new plstream;
pls->sdev("extqt");
pls->plsetqtdev(...);
Regards
jonathan
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
