zhekov commented on this pull request.
@@ -871,13 +893,24 @@ static gboolean spawn_write_cb(GIOChannel *channel, GIOCondition condition, gpoi
}
+static gboolean spawn_read_cb(GIOChannel *channel, GIOCondition condition, gpointer data); + +static gboolean spawn_timeout_read_cb(gpointer data) +{ + SpawnChannelData *sc = (SpawnChannelData *) data; + + /* The solution for continuous empty G_IO_IN-s is to generate them outselves. :) */ + return spawn_read_cb(sc->channel, G_IO_IN, data);
Would you clarify "was not able to enter commands in the gdb console"? It works for me...
"for which file descriptor this change is made for, right?"
The change is for the spawn client reading from the child process output and error. It should not affect sending data to the child, such as sending a command from Scope to gdb.
"Shouldn't we attempt to become a normal callback again, instead of staying on the timeout source indefinitely?"
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), when the spawn client finally manages to read all data, and the 50ms timeouts will do that fast. But I have no reason to believe that the empty IN-s won't start again as soon as unread data appears on the channel.
The early versions of Scope (way before spawn) used 50ms timeouts as the simpler and most portable variant. They wasted ~10 seconds per hour on a single 2.2 GHz core IIRC. The new timeouts are a hack/emulation, so they may take more. Perhaps you can check that?
It would have been sooo much easier if glib had source suspend/resume...