Hi, Ken -
> Thanks for continuing to push on this Frank.
My pleasure.
> [...] My initial suggestion would be the first of these. A PMNS
> can be loaded without any PMAPI context in play, examples are pmcd
> and pminfo -n <namespace>. So it needs to be per thread, rather
> than per PMAPI context I believe.
Good advice! This change (plus another preceding more-obvious one) is
enough to let "pmwebd -M$ncpus" type jobs survive awhile, and run
generally faster than the single-threaded version. I haven't run the
testsuite etc. yet, so this is strictly RFC:
pcpfans.git branch fche/multithread:
commit 7c15b0df0e245d5aa6172e6ce63486339e1d2b49
Author: Frank Ch. Eigler <fche@xxxxxxxxxx>
Date: Sun Mar 1 17:30:46 2015 -0500
pmwebd multithreading: add -M$ncpus to default pmwebd.options
Live dangerously!
d4dc41f54b9dfae76c8212bb6fbbddf7acdc166a
Author: Frank Ch. Eigler <fche@xxxxxxxxxx>
Date: Sun Mar 1 17:17:57 2015 -0500
libpcp multithreading: curr_pmns becoming thread-specific
The libpcp/src/pmns.c globals curr_pmns & useExtPMNS becoming
per-thread variables, to protect these objects from cross-thread
reuse/conflict.
commit 90b7d2bb340152bd3fe71e62599caba18c894ebc
Author: Frank Ch. Eigler <fche@xxxxxxxxxx>
Date: Sun Mar 1 12:11:33 2015 -0500
licpcp pmNewContext multithreading: don't reuse ac_log between contexts.
This is because different threads owning different contexts on the
same archive file may close them at different times. The ac_log's are
not reference-counted, thus shared pointers can become invalid.
- FChE
|