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