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

Fri Jun 8 09:26:06 EDT 2007

Hello All,
      Just looking through bug list and noticed this thread seems related to
bug 71887, so it could probably be reviewed/closed after this discussion.

Thanks,
Jonathan

On 6/7/07, Paolo Molaro <lupus at ximian.com> wrote:
>
> On 06/07/07 Jonathan Gilbert wrote:
> > What use case requires a managed application to create many hundreds of
> > extremely-short-lived processes every second for any period of time? Is
>
> What matters is that you're adding an unacceptable 25% overhead
> for a corner case that has other inexpensive solutions.
>
> > 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
>
> See my discussion of even using two different MS runtimes.
>
> > support of mixed assemblies and COM interop eventual goals of mono (two
> > independent goals, with much more activity on the latter)?
>
> I never heard of anyone interested in supporting mixed mode assemblies:
> for us it is a completely uninteresting case since it would work only on
> windows, so if someone wants the feature he will have to implement it
> (like Jonathan is implementing COM support).
> The important thing to note is that we're much more likely to get
> compatible serialization than mixed mode support. And mixed mode and COM
> are only 2 examples of many features that are valid only for windows and
> that we don't have plans to implement. We're certainly not going to
> break execution of many programs for this corner case that has perfectly
> valid, simple and not buggy solutions.
>
> > 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.
>
> Interoperability doesn't include not being able to run some .net programs
> which is what your solution would do.
>
> > >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.
>
> Microsoft provides different runtimes on the same box.
>
> > >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
>
> First, it is trivial to make it run as I pointed out already two times:
> use the Linux binfmt support (third time). Miguel is too lazy to do it
> so he committed something like your first patch on Linux, which works
> since there is only one working .net runtime there. So don't worry about
> Linux. Your issue is only related to windows and it has never been a
> problem on Linux.
>
> > 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
>
> A documented behaviour is a hack while breaking execution of programs as
> you suggest is not?
>
> > 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.
>
> Breaking execution of .net programs with no way to fix it is going to
> alianate many more people (which is exactly what you suggested above:
> just don't use mono: we want people to use mono, not drive them away
> as your solution does).
>
> > If argc is 0, then argv[0] == NULL (or the platform is non-compliant).
> Do
> > we support any non-compliant platforms?
>
> Point taken, you're right on this one.
>
> > >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?
>
> Sure, in fact Process.Create() is supposed to call the operating system
> and make it execute the program you told it to and on windows that means
> eventually executing with the Ms runtime (it's the OS that does that).
>
> > >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.
>
> Sure that's why the problem that you said is a problem on Linux isn't,
> so we don't need to add any slowdown and unmaintainable code to the
> Process class.
>
> > >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?)
>
> 1.1 is a different runtime (the runtime includes mscorlib etc, so even
> if the jit binary is the same, mscorlib and hence the runtime is
> different) and it is binary-incompatible wrt serialization and other
> issues, which exactly proves my point that Process.Create() is in no
> way guaranteed to execute with the same runtime (remember that your
> original asserted reason for your hack was serialization compatibility).
>
> > 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.
>
> You can't guarantee that if you use any third-party program, which
> is one of the reasons you can have .config files specify the runtime
> (instead of having a .config file you'd have to use a batch file for
> mono, big deal).
>
> > >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.
>
> Neither did I, but I read the documentation and you can look it up on
> the web, too: Process.Create() has no way to guarantee that a program is
> executed with the same runtime (and for very good reasons). As such, for
> the sake of interoperability which is so dear to you and also because it
> would be a bug to do, we won't force down our users throat the decision
> as to which runtime to use to execute any program: if the user didn't
> specify one (by explicitly using mono to run it) it's up to the
> operating system to decide.
> Until you realize that your solution breaks execution of programs
> and prevents the user from ever being able to fix it (and no, not using
> mono at all is not a solution), you won't be able to convince anyone.
>
> lupus
>
> --
> -----------------------------------------------------------------
> lupus at debian.org                                     debian/rules
> lupus at ximian.com                             Monkeys do it better
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070608/c7f09b34/attachment.html