Nathan Scott wrote:
Well...I don't think you'd need locking and threading everywhere. You
could extend the existing 'context' abstraction in such a way that the
'current context' pointer is per-thread and that no context can be
current in more than one thread.
----- "Greg Banks" <gnb@xxxxxxxxxxx> wrote:
None of the various PCP libraries are thread safe. This was a
decision right at the very beginning (not an accidental oversight).
Aha. That's the situation I remember from my days digging around in
libpcp source, apparently it's not improved in the meantime. That's
Heh, or rather "apparently it's not regressed in the meantime". ;)
Putting locking and threading API calls throughout libpcp would be a
bit of a nightmare, and arguably overkill... and plenty of use of PDUs
happens between pmcd and pmdas too, so we're definately talking adding
useless overhead there (already "threaded" there!).
This means that pmNewContext(), pmDestroyContext() and pmUseContext()
would need some work, but none of the remainder of the code that uses
contexts. Then it's just a matter of dealing with all the existing
static variables by doing one of:
* change the logic not to need them, or
* push them into the context, or
* make them per-thread using __thread, or
* as a last resort, put a mutex around them.
If this socket connection delay issue is a genuine problem for people
(as someone using pmchart everyday, with remote hosts around the globe,
I tend to find it *not* a major problem ... but maybe I'm just lucky!),
You are lucky. I use it daily with hosts located two rooms away and it
locks up for several seconds each day.
then my vote would be for separate processes per-context communicating
with a common graph/UI process via mmap or something like that.