<div dir="ltr"><div><div><div>Thanks for the feedback<br><br></div>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: <a href="https://github.com/smokingrope/mono/commit/8837a69d202ddb7d8350ebd052ff44d9e889a627">https://github.com/smokingrope/mono/commit/8837a69d202ddb7d8350ebd052ff44d9e889a627</a><br>
<br></div><div>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. <br>
        I reused the poll() wrapper from the sockets implementation, (as MonoIO.PollFD) so i assume that is ok. <br>        I am re-using the existing CreatePipe() function for pipe creation, so that behaves the same as before. <br>
        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.<br>
</div><div><br></div><div>A new problem has presented itself, which some expert feedback would be appreciated. Based on the sample code:  <a href="http://msdn.microsoft.com/en-us/library/bb546102.aspx" target="_blank">http://msdn.microsoft.com/en-us/library/bb546102.aspx</a><br>
<br></div><div>  1) Process.Start() is called on the server application to launch the client application<br></div><div>  2) When the client application is started, it will inherit the pipe handle and eventually start using it<br>
</div><div>  3) The server application calls DisposeLocalCopyOfClientHandle()<br></div><div>  4) The server writes to the pipe</div><br><div><br></div><div>   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 :) <br>
  <br>  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. <br>  <br></div><div>  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.<br>
<br></div><div>I also would still appreciate some feedback on the handle inheritance problem.<br></div><div><br></div>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 <a href="http://MS.NET">MS.NET</a> implementation).<br>
</div></div>