[Mono-dev] Anonymous Pipe Stream Implementation

[Atsushi Eno]

Thanks, that's quite a lot of effort :)

Whoever touches the runtime part should judge if making changes in the 
runtime/icalls in this manner is acceptable. I'm particulary not sure 
about using icalls from System.Core.dll.

Also we cannot expose any internal API as public, for example:
https://github.com/smokingrope/mono/commit/8837a69d202ddb7d8350ebd052ff44d9e889a627#L7R437

Atsushi Eno

SmokingRope wrote:
> Thanks for the feedback
>
> I started this project merely as an investigation into whether it was 
> even possible to implement in unix, and so hadn't really thought far 
> enough ahead as to sharing it. The code is now pushed to a fork on 
> github: 
> https://github.com/smokingrope/mono/commit/8837a69d202ddb7d8350ebd052ff44d9e889a627
>
> In terms of compatiblity i have not needed to change any existing dll 
> references. At this point i have added two internal calls to the 
> corlib\System.IO.MonoIO class. Perhaps you could look over these new 
> internal calls and give a little more specific advice on what (if 
> anything) needs conditioned out.
>         I reused the poll() wrapper from the sockets implementation, 
> (as MonoIO.PollFD) so i assume that is ok.
>         I am re-using the existing CreatePipe() function for pipe 
> creation, so that behaves the same as before.
>         The GetPipeHandle() internal call just initializes a handle 
> that was inherited from a parent process in mono's file descriptor 
> table, which would not strike me as a compatibilty concern on it's own 
> as it's only doing mono platform work.
>
> A new problem has presented itself, which some expert feedback would 
> be appreciated. Based on the sample code: 
> http://msdn.microsoft.com/en-us/library/bb546102.aspx
>
>   1) Process.Start() is called on the server application to launch the 
> client application
>   2) When the client application is started, it will inherit the pipe 
> handle and eventually start using it
>   3) The server application calls DisposeLocalCopyOfClientHandle()
>   4) The server writes to the pipe
>
>
>    There is a synchronization issue between when 2 and 3 run, because 
> in my testing, sometimes the Process.Start() call has not fully 
> completed launching the child process, and closing the client handle 
> on the server side cause the pipe to be broken before the client is 
> fully booted. Because the pipe is broken step 4 should fail, though 
> right now this isn't quite happening :)
>
>   With a Thread.Sleep(10) in DisposeLocalCopyOfClientHandle() the code 
> seems to work about 50% of the time on my machine. With no sleep, the 
> pipe seems to be broken every time.
>
>   With the technical explanation out of the way, is there any way i 
> could wait / yield, and force the Process.Start() to complete 
> launching the client before DisploseLocalCopyOfClientHandle() 
> complete? I can certainly find some threshold where Thread.Sleep() 
> reliably fixes the issue on my machine, but it may not be nearly as 
> reliable across platforms either, and may need to be pretty huge 
> (multiple seconds maybe?) to really get good reliability that way.
>
> I also would still appreciate some feedback on the handle inheritance 
> problem.
>
> There aren't any tests yet, and i'm pretty severely violating the 
> coding standards document at this point, so both of those things are 
> still on my todo list. I'd also like to throw together the win32 
> implementation as well (something that would be compatible with the 
> MS.NET <http://MS.NET> implementation).