zhekov commented on this pull request.
> @@ -967,6 +1002,25 @@ static gboolean spawn_read_cb(GIOChannel *channel,
> GIOCondition condition, gpoin
sc->cb.read(buffer, input_cond | failure_cond, sc->cb_data);
}
+ /* Check for continuous activations with G_IO_IN | G_IO_PRI, without any
+ data to read and without errors. If detected, switch to timeout
source. */
+ else if (SPAWN_CHANNEL_GIO_WATCH(sc) && status == G_IO_STATUS_AGAIN)
+ {
+ sc->empty_gio_ins++;
@b4n
Citing myself: "The empty gio IN-s for a channel seem to start as soon as data
appears on that channel, and never end. Or, they may end after some
unpredictable time (minutes or more) [...]"
AFAICT, the "successful" read attempts are only such because there incidently
happens to be any data when the subsequent G_IN is delivered.
If the counter is reset, there is a risk that small portions of data will be
read at, say, each 100 G_IN-s, and Geany/Scope will work, but slow. I chose 200
as the limit because it does not cause a noticeable *one-time* slowdown before
switching to timeouts even, on slow CPU-s.
I'm not against decrementing the counter, or even substracting some fixed
ammount <= 10, if you consider that more safe. Just don't do it after the
counter reaches maximum, it's also an indicator that input has switched to
timeouts.
--
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#discussion_r155500981
