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 _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
