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

[zhekov]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.geany.org/pipermail/github-comments/attachments/20171207/4e195931/attachment.html>