<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 16 October 2013 04:05, Dimitar Zhekov <span dir="ltr"><<a href="mailto:dimitar.zhekov@gmail.com" target="_blank">dimitar.zhekov@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, 15 Oct 2013 11:29:17 +1100<br>
Lex Trotman <<a href="mailto:elextr@gmail.com">elextr@gmail.com</a>> wrote:<br>
<br>
A good news first: using a bit of Scope code, I was able to pipe<br>
12.3MB of mixed stdout and stderr output into Geany, in async mode,<br>
for just a few seconds.<br>
<br>
There is a delay when scrolling the messages down, and the scroll bar<br>
gets updated - seems that GtkTreeView does not handle all lines until<br>
you come to them (depending on some options). Pretty reasonable.<br>
<br>
Of course, there will be more tests, especially sync, before I post a<br>
patch to SF Bug #943.<br></blockquote><div><br></div><div>That sounds encouraging, maybe post a PR and just refer to it from the bug.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">[...]<br>
</div>tools.c does replace the selection without checking if the document<br>
is still valid and whether the selection has been changed. Working<br>
with a closed document may cause a crash, so it looks intentional.<br></blockquote><div><br></div><div>Sounds like it should use a synchronous spawn.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">[...]<br>
<br>
</div>The last time FiF-ed, glib did not contain any calls to PeekNamedPipe<br>
or SetNamedPipeHandleState. I am not aware of any way to implement<br>
async anonymous pipe I/O under Windows without these, and see no<br>
reason to check the various glib functions one by one. (Don't be<br>
fooled by "Named", these work for anonymous pipes, and in fact the<br>
win~1 named pipes don't need them as they support event based I/O).<br></blockquote><div><br></div><div>Ok, and Thomas supports you there.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">[...]</div><div class="im">
><br>
> Basically the whole spawning thing needs to be looked at critically,<br>
> especially those uses that do i/o to the child process.  A working version<br>
> of each permutation sync/async, reads/writes/both needs to be put in utils<br>
> and all of Geany should then use that implementation and the callbacks use<br>
> known good idioms.<br>
<br>
</div>Blocking the GTK+ message loop (aka Geany) to avoid document changes<br>
and using blocking pipe I/O are two different things, and we don't<br>
need the later AFAIK.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
A good blocking without rewriting the current code is by displaying a<br>
small modal dialog "Running FOO..." with a Cancel button. The keyboard<br>
and mouse events are redirected to it, keeping the documents fair, and<br>
there's a way to stop a slow process which intentionally blocks Geany.<br>
<br></blockquote><div><br></div><div>Thats a possibility, though some people would find them annoying.  But having their output work correctly is more important :)</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

That being said, I agree we need something better than the current<br>
(a bit naive) implementations, and I know where to find it. :) Whether<br>
the leading developers will accept such changes is another matter.<br></blockquote><div><br></div><div>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). :)</div>
<div><br></div><div>@Thomas,</div><div><br></div><div>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?</div>
<div><br></div><div>Cheers</div><div>Lex</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
--<br>
E-gards: Jimmy<br>
_______________________________________________<br>
Devel mailing list<br>
<a href="mailto:Devel@lists.geany.org">Devel@lists.geany.org</a><br>
<a href="https://lists.geany.org/cgi-bin/mailman/listinfo/devel" target="_blank">https://lists.geany.org/cgi-bin/mailman/listinfo/devel</a><br>
</div></div></blockquote></div><br></div></div>