Open
Description
The Collector documentation only states the constraint that reset()
must be called at least once before the first start()
call.
There is a number of important points that are not addressed and might be useful to formalize, even if they differ from one collector to another:
- reentrancy: Whether multiple instances of the collector can be nested successfully. This is not granted and many collectors cannot because of fundamental reasons, but some can (like dmesg if you don't force emptying the buffer).
- Whether collection can be interrupted and resumed and what will be the result, i.e. the sequence
reset() -> start() -> stop() -> start() -> stop()
. It might mean the output is the logical combination of what happened during the firststart()/stop()
pair and the 2nd one, or it could mean the result of the firststart()/stop()
is discarded (i.e. implicitreset()
onstart()
).
I think most collectors would simply discard the data during the firststart()/stop()
pair by virtue of assigning the results to a single attribute instop()
(vs storing it in e.g. a list of results to be combined later). Collectors storing the data straight in their output file would also likely behave this way. - What happens on invalid sequences, such as
reset() -> stop() -> stop()
: that's the easiest to fix, as we could enforce a state machine with metaprogramming inCollectorBase
and raise a consistent exception. We simply need to apply a decorator that checks valid transitions onstart()
,stop()
andreset()
usingCollectorBase.__init_subclass__
. This would avoid having to make a breaking change (e.g. have subclasses define_reset()
and let a genericCollectorBase.reset()
handle the check)
Metadata
Metadata
Assignees
Labels
No labels