Nathan Scott wrote:
----- "Greg Banks" <gnb@xxxxxxxxxxx> wrote:
Well...I don't think you'd need locking and threading everywhere. You
By "everywhere" I mean on every (runtime) code path. pdubuf.c would
need locking or rewriting or thread-localising or whatever - everything
goes through there, including pmcd and pmdas.
Yep, that stuff is very mucky indeed.
You are lucky. I use it daily with hosts located two rooms away and
it locks up for several seconds each day.
Hmm, I find that very hard to believe. (Would you believe several
milliseconds?!?) Is your update interval is insanely high?
Default, I believe 1 second.
Where
is the root cause of your lockups? (why does it take that long to
talk to a machine two rooms away?)
If I knew that I could probably do something about it!
then my vote would be for separate processes per-context
communicating
with a common graph/UI process via mmap or something like that.
Sigh.
Why the need for threads over processes? (when pmcd/pmda end is already
using processes for this class of issue ... so why threads on the client
end?)
Conversely, and from the application programmer's point of view, why
not? Why use processes and pipes and other 20th century artifacts when
we have shiny modern threads which are supported by every part of the
toolchain and every library that goes into an app, *except* libpcp?
More seriously: every reason that anyone chooses threads. Faster access
to shared data structures. Cleaner semantics for process death. Fewer
copies of data segment pages in RAM. One copy of each file descriptor
including the ones you didn't know about.
--
Greg.
|