Marc Lehmann wrote:
On Wed, Apr 09, 2008 at 06:15:27PM -0500, Brandon Black <[EMAIL PROTECTED]>
wrote:
Regardless, if poll() returns zero there's no point in examining revents
anyways right?
The extra test might slow you down when you need it most, when you are in
a tight loop handling I/O events, especially when it is hard to predict.
That makes the whole issue moot.
Well, I'd rather have bugs fixed, especially in tools like valgrind that I
use myself.
You might not care about the quality of the software you use, but I do. And
when I use valgrind, I expect useful and good results, not false positives.
Think about how much time you and I already have potentially wasted on this
valgrund bug. This wouldn't have been neccessary if valgrind were fixed.
And yes, you might not care, but I am happy when _other_ people who find
out about these issues get the real bug fixed, so _I_ do not have to waste
time investigating them. With your attitude, everybody would just slap
workarounds around kernel bugs and everybody would have to reinvent those
workarounds again and again.
I have different standards.
No need to get personal with attacks on my "standards". If it's a
valgrind bug then fine, it's a valgrind bug.
If anything you gain some performance by not scanning the poll_fd's in
the case of a timeout with no events occuring.
Micro-optimisations like these often don't have the intended effect,
though, you have to look at the larger picture.
Besides, the point is not avoiding code changes to libev - if you had
looked, you had seen that I already added a workaround, despite having no
indicationg of this beign a real problem.
The point is a) fixing a real bug in a tool people rely on (valgrind) and
b) helping others by epxloring and fixing the issue, instead of blindly
applying some kludgy that might not even be necessary and letting others
stumble upon the same problems.
Look, either the change you applied to skip scanning revents on a retval
of zero is a "blind kludge" or an optimization that happens to
workaround a valgrind bug. If you think it's a blind kludge and its
optimization value is dubious (or even negative), then by all means
don't apply the workaround, nobody's forcing you.
And yes, you might not care, but that doesn't mean it's good if other
people care for the quality of their and other's software. Free software
lives from people who *do* care about bugs, otherwise free software
wouldn't have the high quality that is (usually) has.
All I've done here is seen a valgrind output flagging a potential
problem and tried my best to follow up on what it means. I don't see
how that is any indication that I lack standards.
-- Brandon
_______________________________________________
libev mailing list
[email protected]
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
