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

[Jonathan Gilbert]

At 04:39 PM 6/6/2007 +0200, Paolo Molaro wrote:
>On 06/06/07 Jonathan Gilbert wrote:
>> This makes having 'mono' in $PATH an official requirement for mono to
>> operate correctly...
>
>For some things it's already required to have the mono tools installed
>in $PATH (see for example the use of codedom and mcs...).

I see.

>> As Robert Jordan pointed out, this means it will have no effect on Windows.
>> For this reason, and also because I prefer managed code, I've rewritten the
>> support into Process.Create (attached). You can choose which patch you wish
>> to apply :-) (I couldn't resist answering a question in a LAMESPEC comment
>> and correcting a minor error in another comment; you may split off or omit
>> those parts of the patch if you think they are inappropriately mixing
>> changes.)
>
>The managed version of the patch is completely unacceptable, IMHO.
>It duplicates a large amount of code and it will slow down process
>execution a lot for a tiny corner case.

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.

>> But it is not inherited. If a tool is running a program which could
>> potentially spawn a child process, that child process could potentially not
>> start at all, or start with the wrong runtime. I mean, I think it's a fair
>> assumption that if anyone is using mono to run .NET apps on Windows,
>> they're doing it for a reason, and for that same reason they would want
>> child processes to also run under mono.
>
>It's not clear at all that is what they mean. On windows a managed
>binary is always run by the MS framework unless you explicitly execute
>mono prog.exe: I don't think this basic expectation should be subverted.
>If someone wants to run a program with mono he can simply execute mono
>directly.

Well I've never had that basic expectation. I've always felt that the same
runtime should be used for all child processes of a managed process, and
there are some practical reasons beyond the symmetry of it. For one thing,
while remoting is compatible, it is not perfect. Mono<->mono is guaranteed
to work, but Mono<->MS.NET continues to have issues for a number of the
framework classes. One of the strongest tenets of .NET for me has always
been that the same *binary* will work in the same way on all platforms and
with any run-time, and child processes being created under a different
run-time completely violates that.

>> +	if ((argv [0] != NULL) && (argv [0] [0] != 0))
>> +		g_setenv ("MONOEXECUTABLE", argv [0], TRUE);
>> +
>
>argc can be 0 and this can cause a segfault.

Are you sure? Even if argc is 0, argv is still NULL-terminated, is it not?

>If we use anything like this the env var name should be MONO_EXECUTABLE.

Paint that bikeshed whatever colour you like.

>That said, the code to get the mono binary is not correct (argv[0]
>can be anything).

Sure, but in 99.9% of situations, it will be something that the shell can
resolve to the same binary that launched the current process. The
situations where it does not are user-error situations, where people are
doing odd things probably intentionally.

>So, the starting point is that trying to execute a managed assembly
>on windows must use the .net runtime (by means of CreateProcess)
>and on any other system it should be considered pretty much a bug
>(or you should use the linux binfmt registration).

Sorry? You're saying that the use of Process.Start to launch a child
process is a *bug* and that is not open for negotiation?

Jonathan Gilbert