> -----Original Message-----
> From: pcp-bounces@xxxxxxxxxxx [mailto:pcp-bounces@xxxxxxxxxxx] On
> Behalf Of Ken McDonell
> Sent: Friday, 22 January 2016 8:17 PM
> To: 'Nathan Scott' <nathans@xxxxxxxxxx>
> Cc: 'pcp developers' <pcp@xxxxxxxxxxx>
> Subject: Re: [pcp] pmRegisterDerived return values
> ...
> Just by the way, we use thread private data in other places ... are
> these potential hand grenades waiting for a Python detonator?
I've been think about this ... the problem is even larger than thread
private data. We have some routines in libpcp that are NOT thread safe
because they call underlying kernel/run-time routines that are not
thread-safe. And we explicitly check to see if they are ever called from
more than a single thread.
This is a BIG problem ...
kenj@bozo-vm:~/src/pcp/src/libpcp/src$ grep PM_MULTIPLE_THREADS *.c | wc -l
40
If the Python run-time is choosing different threads to enter libpcp at
different points in time, this will blow up.
But, wait, it gets worse ... libpcp_pmda is not thread safe and never has
been (there is no need for multiple threads on the pmcd-pmda-pmcd code path
for PMDAs implemented in conventional programming languages), so goodness
knows what evil is lurking below the Python wrapper for libpcp_pmda.
And as for thread private data, we have plenty of them in libpcp ...
kenj@bozo-vm:~/src/pcp/src/libpcp/src$ grep TPD *.c | wc -l
67
This seems like a class of problems that needs to be solved by stopping the
Python run-time from launching multiple threads between the Python code and
the PCP libraries, not band-aiding in the PCP libraries.
|