On Tue, 2004-05-18 at 17:52, Branko Èibej wrote:
> You'll have to be a bit more persuasive than that. Either you use them
> in the logging implementation, or in the code, or in syslog, or
> wherever. Bout you can't reasonably avoid them in this case. Note that
> the problem with golobal variables is when they're in a (possibly
> shared) library. In this case, it's one variable in svnserve, we can
> ensure single-threaded initialization, and it's readonly from that point
> onwards.
It's bad design wherever you put them (except when you really can't
avoid it, like signal handlers). Perhaps people will want different
logging levels for different repositories, and global variables prohibit
that.
We have this nice driver-state structure in svnserve. No reason not to
use it.
> Evaluating the logging level is not the issue. Evaluating the function
> parameters during the call _is_. I don't have numbers handy, but believe
> me, I know from personal experience that it _can_ become an issue when
> the logging is verbose enough.
Show me any place where there's any reason to evaluate a function (cheap
or expensive) in the arguments to the log function.
For that matter, show me a logging system in wide use which doesn't make
this "basic mistake."
> If the logging isn't even potentially
> verbose enough for this to matter, then it's also next to useless for
> locating bugs.
This is the third time I've said it, without acknowledgement from you:
without invading the libraries, we could put log calls between every two
lines of code in svnserve and it would still be totally useless for
finding most bugs, including the one which triggered this thread.
svnserve is only 1500 lines of code, with 50,000 lines of library code
behind it. The deepest you're going to get is stuff like, "this client
issued this top-level RA request," which might sometimes help you
reproduce the bug, at most.
> All in all, I'd prefer to go with a mature library like log4c because
> it gives us lots of control over the output format, output location,
> logging levels, and such.
What makes you say log4c is a "mature library?" The version number?
Its web page calls it a work in progress, and claims it has never been
compiled on a *BSD. It's not vaguely portable. It requires expat,
which stinks of severe overengineering.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 19 00:33:48 2004