@J-Dunn the problem this change is intended to mitigate a bug in GIO. It is not a fix, it just limits the damage by limiting throughput in the subprocess pipes and in doing that slows operation and increases CPU usage. It is a change in Geany, not in Scope so it is not limited to subprocess IO in Scope and would apply if triggered by any of Geany's many subprocess operations: builds, find in files, context commands etc.

But the bug appears to only exist in some versions of GIO so it clearly is caused by changes made in the GIO code.

@zhekov is likely correct in stating that the mitigation is not triggered by anything other than the particular usage in the Scope plugin for the version of GIO he examined, but that is relying on the people who caused the bug in the first place to not make any other changes to GIO that affect that current incorrect behaviour so as to not affect other users.

Other than examining the code of many versions of GIO, testing is the only way of telling if anything else is affected. Especially on Windows and OSX where the subprocess code is likely different to that on Linux. I expect this has not been tested on those systems (and hence my ping of known users there, apologies to those I missed). Also since the Scope plugin does not currently run on GTK3 and so nobody with GTK3 has any reason to apply the patch I bet it hasn't been tested their either, sure its should not matter, but its a bug, who knows.

So in relation to this hack testing is not just good policy, its essential to provide a feeling of comfort that the hack won't be triggered outside the intended situation. Note its not definitive, just an indication that it seems to be ok.

Maybe the solution is for a copy of the spawn code with the patch to be made in scope so it only applies to Scope.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.