[prev] [thread] [next] [lurker] [Date index for 2006/12/27]
> 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