Hi, Ken -
>> ... wherein a missing pcp.conf file was deemed a "FATAL PCP
>> ERROR" and resulted in a process exit(). This sort of error handling
>> is not appropriate within a library, as the application is better
>> equipped to judge the severity of the problem.
>
> Ahem, I beg to differ here.
>
> If pcp.conf is missing then pretty much NOTHING works in pcpland
> ... this really is a fatal error.
But there is in general more to an application than pcpland; pcpland
may not even be central to its purpose, or failures may require
alternative cleanup, or recovery, or logging. libpcp cannot know and
must not assume.
> [...]
> And if the semantics of pmGetConfig() is to be changed, then we'd need
> to go find all the uses of pmGetConfig() and validate that they are
> indeed making an appropriate judgement ... a quick scan shows
>
> 179 uses of pmGetConfig
> none in the context of an if ()
> only 37 of these are of the form ... = pmGetConfig()
>
> So I'd be willing to guess that there are 150+ cases where the code
> has been written with the assumption that if pcp.conf is not available
> there is no point continuing.
Thanks - I'll go audit them. If they can crash & burn with an
empty-string return value (same as if SOMEVAR was not defined), I'll
look into them closer. Are you expecting some code to be fragile with
respect to misconfigured pcp.conf, such as with incorrect SOMEVAR
values?
> Note that pcp.conf not being available is at a whole different level
> of severity to SOMEVAR not be defined in pcp.conf.
Considering that pcp.conf is a list of many SOMEVAR's, which ones or
how many of them build up to a whole different level of severity?
- FChE
|