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

[Jonathan Gilbert]

At 04:33 PM 6/7/2007 +0200, Paolo Molaro wrote:
>On 06/06/07 Jonathan Gilbert wrote:
>> penalty? Surely the overhead of actually setting up a 10,000 child
>> processes totally eclipses a 5 second penalty.
>
>Well, maybe on windows it does. My 3 year old laptop can execute 2500
>processes in those 5 seconds.

What use case requires a managed application to create many hundreds of
extremely-short-lived processes every second for any period of time? Is
that something you do frequently? The overhead can also be limited to Mono
on the Win32 platform. Can you create 500 child processes per second on
Windows?

>> >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
>
>Maybe because you have only a single use-case in mind?
>What if you want to execute a managed C++/COM app or something else that
>we still don't support in mono? Forcing the runtime to execute it with
>mono will only get you a crash and worse, there is no way for you to
>fix it, because your code prevented any possibility of running the program
>with the MS runtime.

Firstly, if you run a managed C++/COM app in .NET, it will never
"accidentally" start a managed child process using mono. Secondly, aren't
support of mixed assemblies and COM interop eventual goals of mono (two
independent goals, with much more activity on the latter)?

You say that there is no way to fix it, but consider: If you are not on a
Windows machine, there is no way to make it work *anyway*. If you are on a
Windows machine, there is a very clear way to make it work: don't launch
the parent process with Mono. Over the years I have seen many cases where
something has been rejected for Mono because it would have allowed people
to write managed applications that *only* Mono could run. Of course, there
are yet many ways to do that, but the emphasis has always been on
interoperability.

>> 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.
>
>The Process class is for telling the operating system to execute child
>processes, there is nothing in the documentation or anywhere else about
>"using the same runtime".

That documentation is written by Microsoft.

>I understand that you your scenario needs a solution, but hacking
>Process is not it. What if you use "prog" instead of "prog.exe"
>as the name of the executable? Windows will look for prog.exe
>and run that, right? When you want to test with mono you'll have
>a test directory with a prog.bat batch file and you can put that
>directory at the start of your PATH environment var and execute your
>program with mono: windows will load the batch file which in turn uses
>mono to execute your prog.exe managed assembly.

Yes, yes, this works, but it makes an enormous assumption: that I am the
author of the application in question. If I am merely a consumer who has
purchased a .NET application and wishes to run it on Linux, and it fails to
run because of something Mono could easily have taken care of, that is, in
my eyes, pretty much Mono's fault. As far as I'm concerned, depending on
the fact that one platform will see "prog" as a binary and another will not
and will instead search for and find "prog.exe" is a much worse hack than
doing something that the documentation does not comment on and
automatically do what, for the majority of users, is the "right thing".
Asking code authors to use Process.Start on something other than the actual
program filename and at the same time asking end users to create batch
files or shell scripts just for the privilege of using Mono to run a
program they did not write and about the internals of which they know
nothing is completely unacceptable; it will alienate people.

>> Are you sure? Even if argc is 0, argv is still NULL-terminated, is it not?
>
>It is not defined to be NULL terminated.

I quote:

  5.1.2.2.1 Program Startup
  ...
  166 If they are declared, the parameters to the main function shall obey
the following constraints: 
  167 * The value of argc shall be nonnegative. 
  168 * argv[argc] shall be a null pointer. 
  169 * If the value of argc is greater than zero, the array members
argv[0] through argv[argc-1] inclusive shall contain pointers to strings,
which are given implementation-defined values by the host environment prior
to program startup. 

If argc is 0, then argv[0] == NULL (or the platform is non-compliant). Do
we support any non-compliant platforms?

>> >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?
>
>No, executing a managed assembly that way can be considered a bug,
>just like not using PathSeparator for directories: anywhere but
>windows it is \n, like anywhere but windows a prog.exe is a simple data
>file and not an executable (modulo the binfmt registration I mentioned).
>And it is definitely a bug to assume that the same runtime will be used
>and I bet that this happens also when having different MS frameworks
>installed on windows (run a program with the 1.1 framework and make it
>execute a program that requires 2.0, or play some tricks with the 32 or
>64 variants of the frameworks on a 64 bit box).

This paragraph goes all over the place! I'll try to respond to each point
individually.

>No, executing a managed assembly that way can be considered a bug,
>just like not using PathSeparator for directories: anywhere but
>windows it is \n

I have yet to encounter a platform where the path separator is '\n'. Even
assuming you meant '/', there are platforms which use other characters,
such as ':'. In any event, I have never used Environment.PathSeparator; I
just use Path.Combine and let it figure out the details. Why can't I also
use Process.Create and let it figure out the details?

>like anywhere but windows a prog.exe is a simple data
>file and not an executable (modulo the binfmt registration I mentioned).

The same applies to the binary format of any other operating systems; aside
from hacks and wrappers added specifically to support it, a Linux binary is
"only data" to a FreeBSD machine, and so on. The more abstract one becomes,
though, the closer a file becomes to a universal binary; most platforms can
be configured to run .NET binaries directly, and all platforms can be
configured to run scripts (Perl, Python, Ruby, etc.) directly.

>And it is definitely a bug to assume that the same runtime will be used
>and I bet that this happens also when having different MS frameworks
>installed on windows (run a program with the 1.1 framework and make it
>execute a program that requires 2.0,

As I understand it, unless you are embedding the run-time, the newest
version is always used to launch any .NET application on Windows. Which BCL
is used is chosen based on where the metadata in the EXE refers, and the
bytecode and icalls is backwards-compatible. Launching a .NET 1.1
application loads it in the 2.0 VM but runs it against the 1.1 BCL. (Mono
behaves the same way, does it not?)

Launching any .NET application from any other on Windows *is* guaranteed to
use the same run-time, but obviously there will be remoting
incompatibilities and other issues communicating between two processes if
they are using different versions of the BCL. However, any application
which has been designed with a child process communicating back to a parent
process will have both the parent and the child compiled for the same
run-time version against the same BCL.

>or play some tricks with the 32 or
>64 variants of the frameworks on a 64 bit box).

Unless you are embedding the run-time, I'm pretty sure you have no control
over this. I could be mistaken, however; I have never played with a 64-bit
Windows box.

Jonathan Gilbert