[Geany-Devel] Ping on Bug #943 - windows build command

[Dimitar Zhekov]

On Tue, 15 Oct 2013 11:29:17 +1100
Lex Trotman <elextr at 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.

> > Any idea why is that? What comes to ming is blocking Geany until the
> > command finishes, to be sure that the current document still exists and
> > it's selection is unchanged, and thus can be safely replaced with the
> > command output.
> >
> 
> This would be a correct reason to block Geany, but deliberately, not by
> accident.

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.

> > I can emulate the (non-)blocking behaviour, but am not sure if this
> > flag currently has any effect under Windows, considering it's buggy
> > implementation of g_io_add_watch and g_io_channel_set_flags for
> > pipes (which are the problem to fix in the first place).
> >
> >
> Or possibly try the more complicated GIO g_input_stream_read_async() and
> friends and see if it works on windows.

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).

> > If tools_execute_custom_command really wants to block Geany, the right
> > thing is to spawn the command, and then cycle reading stderr and
> > stdout asynchronously until the command completes, instead of adding
> > I/O watches to the message loop just to block it.
> >
> 
> > The current loop that writes the selection to stdin seems capable of
> > causing a deadlock under Windows too, if the command generates 4KB
> > output and stops before the full selection is written, since we use
> > blocking I/O to write to stdin...
> >
> 
> And not just on windows, if the selection is a whole file it can easily
> exceed the Linux limit of 64k.

I was wondering if there is any limitation under *nix...

> 
> 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.

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.

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.

-- 
E-gards: Jimmy