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