dlls/ntdll/file.c: Use FIXME_ONCE for quieter reports.
mstefani at redhat.com
Thu Jul 15 05:18:12 CDT 2010
Saulius Krasuckas wrote:
> * On Wed, 14 Jul 2010, Chris Robinson wrote:
>> * On Wednesday, July 14, 2010 5:02:59 pm Max TenEyck Woodbury wrote:
>>> 'FIXME's that contain no variable information are completely redundant
>>> after their first report. After the first reminder, the additional
>>> reports are just noise. They add no additional information in terms of
>>> action required.
>> I wouldn't say that. Sometimes the simple knowledge that a FIXME is
>> called a whole lot says enough on its own (eg, in WineD3D, you get a
>> fixme when an sRGB reload occurs, because it's a performance drain; if
>> this happens a lot, it can be taken as a source for performance issues).
>> Sometimes knowing particular a fixme is triggered near to a crash or
>> other behavioral anomaly can say a bit, too.
> Although I stand for *_ONCE implementation, I agree with Chris.
> And there might be some alternative: lets then implement it like a
> Which could print something like a
> "fixme:channel:a_debug_string [repeated N times]"
> This would not oly still tell you approximate frequency of a FIXME, but it
> also would require developer to know reasonable occurence quanta value (N)
> or to tune it later. This (for me) sounds like a way to know the code's
> stochastic behaviour better! Which would be a plus.
>> If such fixmes were only printed once, it would be impossible to see
>> this information without more in-depth testing that most users won't
>> bother with. If the fixme is only printed once and the rest are TRACEs,
>> it would still cause more work and a whole lot more noise (ie. all the
>> other traces) in trying to spot it.
> TRACE_ONCE probably could help in some cases too. There I see another
I fail to see how TRACE_ONCE could make any sense.
TRACE is used to trace the important parts of the code flow. Just
printing a TRACE once is less than helpful; it is waay better to not
print the TRACE at all.
Of course TRACE_ONCE should be defined for symmetry and preventing
somebody wasting time to send a patch with an implementation for it.
Too bad that Alexandre is too nice else that would be something like:
#define TRACE_ONCE TRACE_ONCE_Misguided_developer_detected
> constraint of *_ONCE functionality. "Once" could be per block (eg.
> for-loop), per wrapping function call, per process or even once per
> thread's life.
> Implementing all onces might be difficult, IMHO. Though not all of
> them could be necessary, probably.
> * On Thu, 15 Jul 2010, Dmitry Timoshkov wrote:
>> The patches which silense some FIXME's have been accepted as an
>> exception. That covers the code which is unlikely to be fixed in near
>> future, or the code nobody is working on.
> Then at least replacement of these (ugly by their size, IMHO)
> silence-blocks with a simple FIXME_ONCE seems rational.
More information about the wine-devel