G'day Frank.
Thanks for the feedback ... I've just posted a longish mail with my
proposed solution that was already addressing some of your points, so
I'll just pick up on a couple of things here.
On 23/03/14 14:06, Frank Ch. Eigler wrote:
... (The same tolerance for
pmdaNOTREADY could conceivably also apply to regular pmda traffic,
past initialization.)
Indeed. There are 2 use cases I can think of ... slow start and
distraction once started. My proposal addresses both.
It would be ideal if we could hide any required multithreading within
libpcp_pmda, rather than force the complexity to appear within the
API, or force all the pmdas to copy it. ...
The proposal does this.
... We'd have to be particularly
careful about interfacing perl/python VMs with an appropriate
set of (1?) threads. ...
I need more detail here to compensate for my ignorance. If libpcp_pmda
creates one thread, only when a PMDA flags that it may "slow start" and
the pthread only lives as long as the earlier of (a) pmcd sends a PDU
and (b) the PMDA is ready for business, will this be a problem?
... (Please note that the robustness of
multithreading support in libpcp* may not be as good as its sole user
(pcpqa) may lead one to believe; I recall seeing some problems in an
earlier review. These bugs might crawl out from under the rocks if we
kick them over.)
Can you point me to that review?
In the proposed solution there is no effective concurrency in libpcp ...
for the "slow start" case the pthread is only using the PDU recv and
send parts of the library and the main PMDA cannot be using those parts
of libpcp ... so I think this is safe, even if there is a residual bug
in the mutithreading support. For the "distraction once running" case
there is no multithreading involved in the proposed solution.
A lower complexity alternative solution could be to have the pmda
contract with the pmcd a different timeout for various operations,
e.g., so a particular pmda's startup could be given up to a few
minutes of time rather than a few seconds. These values could travel
within a larger pmdaInterface struct, or perhaps a pmcd.conf
extension.
The problem I forsee with this is that it involves parallel mechanisms
to implement functionality we already have and that demonstrably works
for a PMDA written in C. In addition, I doubt that the "distraction
once running" case can be handled by prior negotiation/configuration
that pmcd knows about (it is an asynchronous event in the life of the PMDA).
|