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).
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
