> From: mono-list-boun...@lists.ximian.com [mailto:mono-list-
> boun...@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 <j...@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.   ;-)
_______________________________________________
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Reply via email to