On Thu, Apr 28, 2016 at 1:40 AM, Henrik Grubbström (Lysator) @ Pike (-) developers forum 10353@lyskom.lysator.liu.se wrote:

...

...

Consider this usage:

object stdout = Stdio.File(); Process.create_process(cmd, (["stdout": stdout->pipe()]);

Is this at risk of failing, where stdout->pipe(Stdio.PROP_IPC) would succeed?

Not currently, as the default type of pipe generated by pipe() is fd_pipe() (which maps to CreatePipe on WIN32 and is IPC capable).

...

Does that imply that PROP_IPC is effectively always implied when creating a pipe?

Not on WIN32.

All currently-supported platforms appear to have IPC capabilities in the default pipe. Would it be worth changing the default from PROP_NONBLOCK|PROP_BIDIRECTIONAL to PROP_NONBLOCK|PROP_BIDIRECTIONAL|PROP_IPC? That wouldn't break any

Oops, I missed looking at the code in Stdio.File. Those capabilities would imply fd_socketpair() and not fd_pipe() on WIN32 (the pipe created by CreatePipe() neither has NONBLOCK nor BIDIRECTIONAL).

current code, and would mean that simple calls to stdout->pipe() would be guaranteed to work (instead of just happening to work).

That's not a supported set of capabilities on WIN32.

Of course, it's possible that circumstances have changed since when fdlib.h was written (~1996 (ie Win95 and NT 3.5)), and that the capabilities have improved. Feel free to test and/or document what the respective capabilities are in more recent implementations of WIN32.

/grubba