----- Original Message -----
> > [...]
> - a pmda-side watchdog thread, to reply with NOTREADY indication to pmcd
> when/if the pmda callbacks are taking too long
*nod*
> - intelligence in pmcd to relay that NOTREADY to the pmapi client
Coding-wise this bit is trivial BTW - in fact, on closer inspection,
it appears to already be implemented! (Ken, do you plan to keep the
PM_ERR_AGAIN return? I think it would be better to switch over to
using PM_ERR_PMDANOTREADY here so the root-cause is clear).
> - intelligence in pmcd to quench further requests to the pmda until it
> is ready (so reply NOTREADY to other clients without even asking the pmda)
This is also already in place in the existing code.
> - yet more intelligence in pmcd to NOT forget about the original pmda
> request that timed out, so that when the pmda eventually finishes,
> the results can get dropped on the floor, then go back into full service
If I'm understand it correctly, one of the clever aspects of Kens approach
here is that fixing this (tough issue, given PDUs may be split arbitrarily)
is not actually required! He's turned horrible complexity into something
that is almost too easy from pmcd's POV... 'tis a cunning plan, Baldrich.
cheers.
--
Nathan
|