On 24/03/14 12:12, Nathan Scott wrote:
----- Original Message -----
[...]
=== PMDA has to have a big think after start up ===
At some point, one of the PMDA callback routines is called and
the PMDA knows it need to do something to reconfigure itself or
probe for something or ... anything that might take longer than
the pmcd timeout.
The current request cannot be serviced before the long delay, so
it will return PM_ERR_PMDANOTREADY to pmcd, then do what needs
to be done, then return PM_ERR_PMDAREADY to pmcd.
Thinking more deeply on this, it occurs to me that one possible
problem here is that the PMDA doesn't necessarily know if it is
going to take a long time. This proposed model, AIUI, would
require that whenever a PMDA *might* take a long time, it has
to tell pmcd, even if it doesn't end up taking a long time.
Yep, that's the bones of the proposal for the "distracted" case. But
not necessarily for the startup case where pmcd would be none the wiser
if it does not send a PDU to the PMDA before the PMDA is ready.
The potential problem there is that pmcd might get some client
request at an unfortunate time, which might have been quickly
satisfied by the PMDA, but could end up telling the client we
had a slow PMDA, when in fact we did not. e.g. I'm thinking of
the pmdaproc case here, where a /proc scan may be quick, or it
may not. It may be possible to tackle this using a thread in
libpcp_pmda which has a timer, and if the timer is not quickly
cancelled then the thread could inform pmcd of the delay as it
is happening?
If I can get the BUSY case to work, then I think we can generalize the
pmdaControl method to provide the sort of semantics you're after here.
|