https://bugs.winehq.org/show_bug.cgi?id=43125
--- Comment #15 from Konrad Rzepecki hannibal@astral.lodz.pl --- (In reply to Kai Krakow from comment #14)
(In reply to Konrad Rzepecki from comment #13)
I'd like to fix this in two steps:
- Make the message less spammy: Only display the message once as long as
there are no readers in irp_queue.
I think this is not needed if you apply 2. This will require unnecessary code running at each call.
The code would be extremely simple. Spamming the message every time would be far more overhead. Have you ever compared D3D performance with spammy FIXME messages against all fixmes turned of? It's a real performance problem so such spamminess has already been fixed in many parts of Wine by the same tooling I'm planning to use.
If you plan to add this anyway, i think i will reduce spamming only little bit. There will be no duplicates for same report. But different report still appear.
At least in my case. I think in my "spamming" irp_queue is not empty all the time. There must be something reading this reports, because otherwise I will have only this messages on screen. Readers must be there almost all the time and disappear only briefly. So periods with empty ipr_queue are (mostly) short and separated and your idea reduce spamming only a little.
I wonder if this message isn't an artifact form time when this code was not placed in critical section...
I don't think there was such a time. Looking at the Git history, it's one peace of a big work all included at once. See commit 1a81022f4e6359f4d6009057db1636041eabada9: The critical section has been there with the addition of the function all at once, including the message.
Author can have multiple versions before commit to official repository. But now nobody knows the truth.