> -----Original Message-----
> From: Nathan Scott [mailto:nathans@xxxxxxxxxx]
> Sent: Wednesday, 20 January 2016 2:46 PM
> To: Marko Myllynen <myllynen@xxxxxxxxxx>; Ken McDonell
> <kenj@xxxxxxxxxxxxxxxx>
> Cc: pcp developers <pcp@xxxxxxxxxxx>
> Subject: Re: [pcp] pmRegisterDerived return values
>
> ...
>
> Real problem arises when we subsequently call pmDerivedErrStr() - this
> is using thread-local-storage for the error message (in libpcp).
> However, from trawling the internets, it seems python may be switching
> the threads underneath us ...
>
> https://docs.python.org/2/c-api/init.html
> "In order to emulate concurrency of execution, the interpreter
> regularly tries to switch threads"
I've been mulling over this more.
Can anyone explain why there are > 1 threads in play here? There is nothing
explicit in bad.py that suggests it will be executed using multiple threads.
Also the GIL is not really relevant here ... I believe as soon we're in libpcp
we already hold the GIL, so only one thread is within libpcp at any one time.
The problem for us is that if Python code with no obvious multi-threading ends
up calling into libpcp with different pthread execution contexts at different
times during its execution we're going to have a problem ... thread-private
data for one, and single-threaded guards in libpcp for another.
|