Hi,
I don't have today, so the results quickly. Short test proram, which writes "The quick brown fox jumps over the stdout/err %d times\n", plus a few characters in stdout to create "valid" gdb output.
Geany, with 10000 iterations: dies at stdout 140, stderr 128. I cancelled it after 2 minutes, then after 30 minutes - same thing. Disheartening.
With 100000 iterations (12.28MB of text):
[C:] emit >& __emit: 1 second +-0.5
[C:] emit [console output]: 2 minutes flat
Scope, with a source_check() modified to handle stdout and stderr only (FiF/build do not write to process stdin): 14 seconds
Scope, without "\n" in stdout (converted to \n when reading gdb output), so the text is joined in GtkTextView-lines of few/several KB (depending on when stderr breaks them): 2 minutes 45 seconds
--
So, it is not the async execution itself that's broken. GIOChannel set_flags and/or add_watch are. Well, we already knew that GLib non-blocking I/O and poll are problematic with win~1 anonymous pipes, and discussed than on the ML. Strictly speaking, win~1 has async I/O with events, not poll, so GLib emulates it with a 2nd thread IIRC...
BTW, I forced stdout and stderr to real non-blocking I/O, and the result was quite strange: emit finishes for ~1 second, but Geany does not receive anything.
-- E-gards: Jimmy