Re: C#, .Net, and Mono

[prev] [thread] [next] [lurker] [Date index for 2006/12/27]

From: peter (Peter da Silva)
Subject: Re: C#, .Net, and Mono
Date: 16:07 on 27 Dec 2006
> One problem with .Net is it sort of makes noises about providing a
> portable api, but it mainly does this by insisting on (stupid) win32
> semantics.

Yes! That's a problem with most portability toolkits - they are based on
the worst common denominator *at best*, and on something that isn't vaguely
a common denominator at *worst*.

In practice, unless you're doing GUI work, the most portable way to do it
is to just pretend that everything's UNIX. Because then it'll run on anything
but Mac OS 9, and thank god that's finally been staked in the heart.

And if you *are* doing GUI work, the most portable way to do it is to use
Tcl/Tk or Perl/Tk for the GUI with callbacks to the portable pretend-it's-UNIX
code.

Because that's the least worst common denominator.

> The problem with DirWatcher is that you specify what things you are
> interested in with a glob expression.  The ECMA spec says that the
> default expression is "*.*".  The fun part is that the ECMA spec does
> not tell you what "*.*" means.  You could presume you should use native
> globbing behavior, which would make your applications nonportable.
> "*.*" matches anything on windows, and only files with a dot on Unix. (I
> have no idea what Mac developers think about such expressions.)

Luckily, Mac is now UNIX, and any crazies who still insist on the Mac OS 9
filename emulation are going to run screaming from .NET/Mono.

> Because Mono has to implement all these "system level" semantics that
> don't exist on unix, it has to create a sort of pseudo-system-wide layer
> itself.  This means that all your Mono processes have to be able to talk
> to each other.

UNIX of course has no mechanism to allow programs to talk to each other. :(

> The way it does this is the first Mono prcess you launch is not really
> your process.  It is a "handler daemon", which in turn runs your
> process.

This is a common design in UNIX, you create a shell and run programs under
it. To let programs know how to coordinate communication there are a variety
of tools. The earliest one was to require the programs to accept a common
first argument, or to simply to define a new file descriptor (eg, fd3) as the
communication port... the Berkeley Pascal compiler used this one, and there
was a statistical analysys package that was quite common at Berkeley that
used both. Or they can share a process group and use the process group ID
as a common synchronization token. The most common scheme, though, is to
pass the token around in an environment variable, the way X11, ssh-agent, and
just about every other system of this type works.

> The life of this "handler" wil be the time that you are still
> running any Mono tasks.  This makes launching and managing pids in
> normal unix ways a real fun task for Mono tools,

Why would that be?

> The fun part about the handler daemon is that it communicates to its
> spawn through a socket and some other mumble in a fixed path from $HOME
> ($HOME/.wapi/mumble if I remember correctly).  Thus if you want to run
> Mono tasks under accounts that do not have their own private $HOME dir,
> they tend to crash and burn.

This is of course hateful for all kinds of reasons. For one thing, what
happens if you're logged in from two places? Of course, that kind of multi
session behaviour is anathema to Windows, and there's probably some hateful
WIN32-related reason for it.

But the most hateful thing of all about this is that if yuo *are* going to
use $HOME/.wabi/mumble as your synchronization point, there's no reason to
require all processes to run under the handler daemon!

I am driven to ask, though, is this actually using $HOME or is it calling
getpwuid(getuid()) to find your home directory?

There's stuff above here

Generated at 03:02 on 01 Jan 2007 by mariachi 0.52