> -----Original Message-----
> From: Nathan Scott [mailto:nathans@xxxxxxxxxx]
> Sent: Friday, 22 January 2016 11:04 AM
> To: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
> Cc: Marko Myllynen <myllynen@xxxxxxxxxx>; pcp developers
> <pcp@xxxxxxxxxxx>
> Subject: Re: [pcp] pmRegisterDerived return values
>
> Hi Ken,
> ...
> I think it may not be quite so bad. I've pushed one simplified
> approach to my git tree, if you could take a look? I went with a non-
> underscore-r name since the original is thread-safe really, and
> modelled it very closely on
> pmParseInterval(3) and similar APIs error handling (which differs
> again to many of the *_r routines, which take buffer+length).
>
> Whaddyareckon? It definitely resolves the bug - verified it with
> extension to the existing python test cases.
What arbitrary rules does the python run time follow when switching threads?
As I understand the original issue, is there may still a problem if the thread
that detects the error is not the same as the thread that tries to copy the
message buffer before the return in the variant function?
That's why I was proposing to carry an extra argument all down the call stack,
so there was no thread private data being used in the *_r() function code path.
Just by the way, we use thread private data in other places ... are these
potential hand grenades waiting for a Python detonator?
|