[Geany-Devel] [geany/geany] a3664f: Fix spawning [synchronous] commands on Windows

[Nick Treleaven]

On 31/10/2012 17:49, Dimitar Zhekov wrote:
> On Fri, 26 Oct 2012 18:44:04 +0100
> Nick Treleaven <nick.treleaven at btinternet.com> wrote:
>
>> On 26/10/2012 17:44, Dimitar Zhekov wrote:
>>> I'm using Geany on win~1 recently, with gtk+2.16 and glib-2.22 (the
>>> minimum versions). g_spawn_async_with_pipes() works fine for me, from a
>>> plugin, for a console application, along with the helper.
>>
>> So redirecting I/O works for stdout, stderr and it works for build
>> commands like gcc, make, grep, etc?
>
> It works between a console program and the plugin that spawned it, with
> {PeekNamedPipe() + read()} and {repeat write() on N ms} calls.

This confused me. Are you saying you use native Windows functions in 
combination with g_spawn? I thought only g_io_add_watch could be used.

>
> Note that instead of EAGAIN, read() may return EINVAL, and write() may
> return ENOSPC. I have no idea how the higher level I/O functions
> respond, and I'm doing async spawn, not sync (though it shoudn't
> differ).
>
> One more thing you must do:
>
> HANDLE h = (HANDLE) _get_osfhandle(fd);
> DWORD state;
>
> if (h != INVALID_HANDLE_VALUE &&
> 	GetNamedPipeHandleState(h, &state, NULL, NULL, NULL, NULL, 0))
> 	{
> 		state |= PIPE_NOWAIT;
> 		if (SetNamedPipeHandleState(h, &state, NULL, NULL))
> 			return TRUE;
> 	}
>
> return FALSE;
>
> for all fd-s used, otherwise read() and write() will block.
>
>> IME it sometimes works and sometimes doesn't, and it might depend on
>> which program is being spawned (e.g. which grep you use). I recently
>> checked the commits on the GLib gspawn-win32 code and there didn't seem
>> to be any relevant fixes.
>
> The anonymous pipe I/O under Win~1 is not marked as deprecated, but all
> documentation says to use overlapped I/O (which is no good for us),
> and the named pipe functions work on anonymous pipes only "for
> compatibility with MS-DOS LAN Manager" (sic!) IIRC, and may be killed
> any time. So it's not much of a glib problem...
>