RFC: More flexible pipe API

[Keno]

@piscisaureus As discussed on IRC and outlined in https://gist.github.com/2879135 and https://gist.github.com/2879181 this makes the pipe API more flexible by giving explicit control over both pipe ends.
I did the windows side of this first as I figured that would be the more challenging of the two implementations and would thus reveal any issues.

[Keno]

Also, I'm getting 4 test failures on both this branch and master: https://gist.github.com/2893501. I investigated the first one (because of the "pipe" in the name I though I had broken it), but interestingly, the failure does not occur when a the debugger is attached which makes me think it might be something race-y.

[piscisaureus]

@loladiro Did you figure out what to do about the issue that you had with ipc pipes the other day?

[Keno]

Yes, I don't really like it, but I made it the other pipe end include a pointer to the pid field in the parent pipe:

+  union {                  \
+    int pid;                \
+    int *p_pid;                \
+  } ipc_pid;                \

If you have a better idea, I'm all ears.

[piscisaureus]

Well, I think the that uv_read_start should just be modified to write the current process pid to the pipe, and (if that didn't happen yet), read the remote's pid from the pipe.

[piscisaureus]

Bump @piscisaureus

[vtjnash]

If it helps, I updated and rebased this pull request: https://github.com/JuliaLang/libuv/tree/upipes

[indutny]

any update?

[vtjnash]

JuliaLang has continued to maintain an up-to-date version of this patch. The latest is part of the https://github.com/JuliaLang/libuv/tree/julia-uv0.11.22 branch, where the relevant commits are generally the first few rebased to be first after the fork. Currently, those are:
JuliaLang/libuv@cd0c19b...839ceed

[saghul]

@trevnorris please hold reviewing this until we are done with 0.12. Also, we need to go over the design before style.

[trevnorris]

@saghul okie dokie. deleted all my style comments to remove clutter. sorry about that :)

[piscisaureus]

@Keno @vtjnash

I believe that if we added UV_INHERIT_OS_HANDLE to [this list[(https://github.com/libuv/libuv/blob/master/include/uv.h#L788), julia could create it's own pipes with pipe(2) or CreatePipe(). You wouldn't need uv_pipe_close_sync(); instead you could close the pipe with the platform-specific close() or CloseHandle().

I agree that it's not the nicest of solutions. Hopefully when we take another fresh look at the child process API we can structure things differently so this wouldn't be so much of a problem.

For now, would this work?

[vtjnash]

that does seem fairly reasonable. if libuv were to also provide uv_pipe_open_from_os_handle and uv_pipe2 functions, I think that would work fairly well.

[tkelman]

@vtjnash do you think we should work on adding that as the first part of a rebase (more like partial do-over) against either master or the 1.x branch? Depending on whether we can get to it before libuv devs could.

[vtjnash]

reviewing the current julia-libuv diff list, it seems quite reasonable to take this approach, it just needs someone to take the time to implement a prototype/demonstration