nathans wrote:
> [...]
>> > There's two parts to this problem. The first part is that patch (for
>> > auto-enabling), the second part is during disabling - where do those
>> > errors go? [...]
>>
>> Yeah, that part is tricky (and really not much better in the pmstore
>> .disable case);
>
> Hmm, not really - life is *much* simpler with pmStore. It is the
> nature of the async operation being introduced here that it removes
> opportunities designed into the protocol to report errors. [...]
When one remembers that clients that use the pure auto-enable model
are doing so with the intent to *abandon* counters when they are no
longer needed, it seems natural to ignore errors during cleanup.
Plus, since every counter addition operation involves a complete
counter removal stage, errors only in the latter are going to be rare.
Clients that need to micromanage papi can to some extent do so with
careful, incremental, exclusive pmstore operations, but even then
there's no way to return to them the richer underlying error
indications. (That's why the nested-errors idea was brought up.
We also lack a warning facility, which could be used to pass
partial-failure type info.)
- FChE
|