Added IteratableGatherer for future zero alloc implementations.

[bwplotka]

Fixes #917

Signed-off-by: Bartlomiej Plotka [email protected]

[bwplotka]

Let's not merge, just yet -experimenting how useful it is.

[beorn7]

This helps to protect the addition and removal of whole MetricFamilies. But it doesn't protect editing existing MetricFamilies in place. For example, if your set of metrics is entirely static, you just want to change a value now and then by directly changing only the Value protobuf message deep down within a MetricFamily, you would still create data races with this approach.

In other words, after At() is called, the iterator has no control over the usage of the returned MetricFamily anymore. You only moved the problem one level down (from the MetricFamily slice to an individual MetricFamily).

[bwplotka]

I disagree, I plan to explicitly mention in the interface that after Next you lose control over memory space pointed by pointer. See GatherIterate method comment. Also see implementation.

I don't see any other type safe way to do it. Even my initial idea with GatherForeach(f func(*dto.MetricFamily) error) error has the same issue - someone might reuse it.

We have to rely on runtime tests and interface comments, unfortunately. But this will work. WDYT?

[bwplotka]

Well - there is one type safe manner. We could tie gathering with encoding in some GatherEncode(encoder) error - but:

• it is a little bit package spaghetti,
• tied to promhttp use as we might have to have this non trivial error mechanism that either stops, continues or panics ...

But might be way to go

[bwplotka]

Anyway, all those extra interfaces are doing one thing -> Gather is locked (: So let's take an easier approach for now and use promhttp Gather with lock..