[Mono-list] MemoryMappedFile not supported?

[Edward Ned Harvey (mono)]

> From: mono-list-bounces at lists.ximian.com [mailto:mono-list-
> bounces at lists.ximian.com] On Behalf Of Michael McGlothlin
> 
> I'm experimenting with writing a local service that I need to be reasonably
> fast. I'd like it to work on Windows, Mac OS, and Linux at least. I've never
> written a service in C# but the first thing I tried for IPC was using memory
> mapped files. Immediately I got a complaint that what I was doing wasn't
> supported under Mono because it didn't jive with Unix.. so I switched to
> creating from a file (as the previous error message told me to do) but it
> seems if the file exists it dies with an error about the file already existing and
> if the file doesn't already exist it dies with an error that the file doesn't exist.
> 
> Is this just plain not the right way to make a fast local service in C#? I'd be ok
> with using pipes or IPC sockets if it is a better idea but in Googling it seemed
> that C# had made these rely on networking for some reason.

You seem to be putting a whole bunch of different types of food into a food processor and then asking different questions about the core ingredients.  I normally wouldn't associate IPC with memory mapped files, and neither one naturally with a "reasonably fast service."  

Not saying there's any problem doing all those things - just that they're separate subjects and it's difficult to separate what you're actually trying to do here, or what your actual problems are.

It sounds like you want to have more than one process, providing some kind of service.  Is that right?  And these separate processes need to communicate with each other, and you were thinking of using memory mapped file *shared* between the processes, as a form of communication channel.  (That's weird, by the way, and I'm not certain it's possible or not.)  

What kind of service are you trying to provide?  Something that listens on an IP port?  Because only a single process can do that.  So if you want to distribute that workload, you're going to have to dedicate a process to just listening on the IP port and relaying the communications off to the other processes which actually process it.

For IPC, please see this thread:  http://mono.1490590.n4.nabble.com/Mutex-Bug-tt4663226.html#none

Long story short, there exist frameworks in mono, and in .NET, but most likely you'll have to actually detect running on windows and handle it differently from unix/linux.  There *are* however, ways to do IPC that are cross-platform compatible natively, such as binding to a high numbered port on localhost.  It's just that this requires a lot of careful management.

For services, in Visual Studio I believe there's a "System Service" project template, and although something analogous probably exists in mono for unix/linux, I have found it's easiest to just create a Console Project, and let initd take care of it.  As an example, here is how I daemonize some easily constructed console project in redhat/centos/ubuntu/debian:

Simply create a file called /etc/init/myservice.conf

	description     "My Service"
	author          "Joe User <joe at example.com>"
	
	# "started network" is rhel/centos terminology
	# "net-device-up" is debian/ubuntu terminology
	# By putting them both here, /etc/init/myservice.conf can be identical, and compatible on either platform
	start on runlevel [2345] and ( started network or net-device-up )
	stop on runlevel [016]
	
	exec /usr/bin/mono /usr/local/myservice/myservice.exe

By the existence of myservice.conf, upstart will automatically bring up the service during reboots.  But it doesn't automatically launch it the first time just because you created that file.  You have to manually launch it once "initctl start myservice" or "initctl myservice start" - I forget which is the correct syntax, but that's what "man" is for.   ;-)