Hi Alan
On Tue, Feb 23, 2016 at 11:00:24AM -0800, Alan W. Irwin wrote:
> Hi Phil:
> On 2016-02-23 11:21- 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
> >
Hi Phil:
On 2016-02-23 23:36- Phil Rosenberg wrote:
> I obviously don't have any idea of the size of ephcom, but Plplot
must have thousands of internal function calls that would need the
return value checking.
I believe there are some 300 functions in our public and private API,
and not all
Hi Alan
Sorry for top posting, I'm replying from my phone.
Just to be clear the strategy I am suggesting is only internal, so that at the
API boundary plplot just returns an error code.
I obviously don't have any idea of the size of ephcom, but Plplot must have
thousands of internal function ca
Hi Phil:
On 2016-02-23 11:21- 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 t
On 2016-02-23 00:50-0500 Jim Dishaw wrote:
>
>> On Feb 22, 2016, at 5:48 PM, Alan W. Irwin wrote:
>>
>> @Everybody: now on to my C idea for thread safety.
>>
>> My idea for implementing that (closely following what was done for the
>> C ephcom library case where David Howells implemented an ephco
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?
T
