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

Dimitar Zhekov dimitar.zhekov at xxxxx
Mon Oct 14 16:15:02 UTC 2013


I'm looking how to fix this famous bug without too many changes, and
found something strange: tools.c runs it's command with spawn async,
but uses blocking I/O to read the data from stdout/stderr.

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.

However, if we block reading stderr on Windows, and the command outputs
4KB (or whatever is the limit) to stdout, that'll cause a deadlock, as
evident by the previous messages in this thread. Same if reading stdout
and the command produces a lot of stderr, though that's unlikely.

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

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

E-gards: Jimmy

More information about the Devel mailing list