[Github-comments] [geany/geany] Handle continuous G_IO_IN-s without any data (#1461)

[zhekov]

Some versions of GLib under Linux continuously generate G_IO_IN-s without any data to read when using recursive channel watch sources, causing 100% CPU load. This patch detects such a situation, and automatically switches the affected source from channel watch to 50ms timeout.

A bit of explanation about the recursive sources. Let's say that a callback displays a modal dialog with an error message, or a prompt, something like that. A new message loop is generated for the dialog/prompt, but the source that initiated it is excluded, to avoid calling it's callback for a second time while the execution is still inside it. But, if the source is marked as "recursive", it will be invoked from the new message loop, provided that the source event conditions are met. It has to be implemented carefully, both in GLib and the application that uses it.

The only spawn() client that currently uses recursive sources is Scope, so the GLib bug manifests there. And a glib bug it should be, IMHO, because (a) no message loop is created which can activate recursion; (b) no recustion takes place (verified); and (c) even if a there was a recursion, the source event conditions are not met: these G_IO_IN-s come without any data to read, which is a bug by itself.
You can view, comment on, or merge this pull request online at:

  https://github.com/geany/geany/pull/1461

-- Commit Summary --

  * Handle continuous G_IO_IN-s without any data

-- File Changes --

    M src/spawn.c (68)

-- Patch Links --

https://github.com/geany/geany/pull/1461.patch
https://github.com/geany/geany/pull/1461.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/1461
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.geany.org/pipermail/github-comments/attachments/20170407/e80decc2/attachment.html>