kenj wrote:
> [...]
> Joining a bit late here ... 8^)>
Thanks for your thoughts!
> Please, if there is any choice, let's not add binary->ascii and
> ascii->binary format conversions on the code path between the producer
> and consumer of high volume and/or low latency performance data. I
> hope the reasons are self-evident to this audience. [...]
(Sure, generally speaking; but for lesser intensity, it could be fine.
Must measure.)
> The mmv model has worked well in the past. [...]
It would be nice if we used it ourselves (outside QA toys), so we
could experience its robustness & utility right in the code we ship.
> [...] There is a lot of pain that has been invested in maturing the
> operational and semantic robustness of the mmv model, so don't
> discount the effort that would be required to get a completely new
> model up to the same production standard.
No doubt. And yet, there are some problems visible to the skeptical eye.
For example, the use of the g1/g2 generation numbers to delimit
"in-flux" times -- it might not be quite enough to prevent TOCTOU
errors. If an app mmv_stats_init's (maybe growing new instances or
whatever) right after the pmda mmv starts a need_reload==1 processing
cycle, some corruption will result.
Similarly, an app that scrambles its mmv shared memory content due to
error or malevolence could likely also harm the shared systemwide
pmda. The pmda seems to trust the data and performs little to no
pointer arithmetic checking on the offsets coming therein. (Plus the
mmv pmda could be used as a dso right inside pmcd, not even isolated
into a process.)
- FChE
|