[Mono-dev] PATCH: Make Process.Start() use thesame'mono'runtime

[mabra at manfbraun.de]

Hi All !

Sorry for my 2 cents.

I am working a lot with processes, both, native as .net related, mostly
under windows, but will be able to keep my code running on both worlds.

What I always expect is, a process is a process, nothing else. Which runtime
runs inside the process is up to the starter of the process. Usually, I
start windows executables, with and without GUI. Even if I start a .net
executable, which is handled by the windows shell to span a new runtime,
that is excactly, what I want to do. The spawned processes should keep
running, even my starter terminated in the meantime. A process is a stronger
isolation level that an appDomain, so I use this for a lot of reasons. If I
need to communcate with the spawned app, I use remoting.

I would never expect to run a new .net executable in the sampe process.
As I said, these are just my 2 cents.

Best regards,
Manfred

Sorry for initially posting accidentally to the original author :-(

-----Original Message-----
From: mono-devel-list-bounces at lists.ximian.com
[mailto:mono-devel-list-bounces at lists.ximian.com] On Behalf Of Jonathan
Gilbert
Sent: Thursday, June 07, 2007 2:28 AM
To: mono-devel-list at lists.ximian.com
Subject: Re: [Mono-dev] PATCH: Make Process.Start() use thesame'mono'runtime

At 05:18 PM 6/6/2007 -0400, Miguel de Icaza wrote:
>Hey,
>
>> I just ran a performance test. The unmanaged implementation adds about 1
>> second for every 100,000 child processes. Even the managed version, which
>> is, as expected, a lot slower, it adds less than 5 seconds for every
10,000
>> child processes. In what situation would this be a severe and noticeable
>> penalty? Surely the overhead of actually setting up a 10,000 child
>> processes totally eclipses a 5 second penalty.
>
>I went with your unmanaged code patch, so we are going with 1 instead of
>5 ;-)

Actually 0.1 instead of 5. It really is a lot faster because it has a lot
less to do and even when it's doing the same thing it's so much more direct
than the FileStream class. At the same time, though, it doesn't fix the
problem on Windows. If I write an app that expects a child process to be
able to connect back to the parent with .NET Remoting, there's a good
chance users'll run into problems if they choose to run it with mono on
Windows. If Microsoft's framework isn't installed, it won't work *at all*;
if Microsoft's framework is installed, there could still be serious
problems with remoting incompatibilities (wasn't there just recently an
e-mail about remoting compatibility for
System.Collections.Generics.Dictionary`2?).

I wonder -- is there any possibility of supporting Windows and making the
(extremely minor in my opinion, but still much larger than with pure
unmanaged code) performance hit a Windows-only thing with something like
#if WIN32? Or is the managed part of the BCL designed to be buildable on
any platform and subsequently used on any other with no changes? I suppose
if Windows users complain about it, it could in the end be done with an
icall which is #ifdef WIN32'd on the C side... Heck, could even check
Environment.OSVersion.Platform (or use whatever better way there may be
available within the BCL for detecting the platform) and disable the
managed check that way. Presumably the overhead on that bitwise test would
be significantly less than actually opening the file and peeking at the
first few kilobytes. :-)

I'm sorry I just won't let this die, but it really feels like only half the
problem is solved because the problem isn't addressed for one of the
platforms mono supports.

>Thanks a *lot* for the patch, every couple of weeks I would think
>"Jesus, how come we have not implemented this" and for one reason or
>another never got around to it.

It was fun writing it :-)

Thanks,

Jonathan Gilbert
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list at lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list