On 16 October 2013 04:05, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Tue, 15 Oct 2013 11:29:17 +1100 Lex Trotman elextr@gmail.com wrote:
A good news first: using a bit of Scope code, I was able to pipe 12.3MB of mixed stdout and stderr output into Geany, in async mode, for just a few seconds.
There is a delay when scrolling the messages down, and the scroll bar gets updated - seems that GtkTreeView does not handle all lines until you come to them (depending on some options). Pretty reasonable.
Of course, there will be more tests, especially sync, before I post a patch to SF Bug #943.
That sounds encouraging, maybe post a PR and just refer to it from the bug.
[...] tools.c does replace the selection without checking if the document is still valid and whether the selection has been changed. Working with a closed document may cause a crash, so it looks intentional.
Sounds like it should use a synchronous spawn.
[...]
The last time FiF-ed, glib did not contain any calls to PeekNamedPipe or SetNamedPipeHandleState. I am not aware of any way to implement async anonymous pipe I/O under Windows without these, and see no reason to check the various glib functions one by one. (Don't be fooled by "Named", these work for anonymous pipes, and in fact the win~1 named pipes don't need them as they support event based I/O).
Ok, and Thomas supports you there.
[...]
Basically the whole spawning thing needs to be looked at critically, especially those uses that do i/o to the child process. A working
version
of each permutation sync/async, reads/writes/both needs to be put in
utils
and all of Geany should then use that implementation and the callbacks
use
known good idioms.
Blocking the GTK+ message loop (aka Geany) to avoid document changes and using blocking pipe I/O are two different things, and we don't need the later AFAIK.
Agree, by sync (synchronous) we tend to mean blocking Geany until finished. By async we mean not doing so. As you say it would be better to achieve it without blocking i/o because of the deadlock risks. Anything that is going to modify the buffer should be synchronous, things like build should be asynchronous.
A good blocking without rewriting the current code is by displaying a small modal dialog "Running FOO..." with a Cancel button. The keyboard and mouse events are redirected to it, keeping the documents fair, and there's a way to stop a slow process which intentionally blocks Geany.
Thats a possibility, though some people would find them annoying. But having their output work correctly is more important :)
That being said, I agree we need something better than the current (a bit naive) implementations, and I know where to find it. :) Whether the leading developers will accept such changes is another matter.
For me, you will be *very* welcome if you can provide a proper set of multi-platform spawn with/without stdin/stdout/stderr that can remove the #ifdef G_OS_WIN32 stuff from build.c that I have been tiptoeing around for years not daring to pass the mouse over it in case it broke (worse). :)
@Thomas,
Sounds like a useful patch, definitely pass it to glib, I'm sure the windows support guy(s?) will be glad of help. In the mean time is it licensed suitably for Dimitar to steal?
Cheers Lex
-- E-gards: Jimmy _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel