Hello, ok great idea. But to support that feature we must have a new configuration property for a service. We should implement that feature later. First we should write the starter process, to implement the ServiceBase class.
Am Don, 2002-11-21 um 19.31 schrieb Bob Smith: > > Well, for web services, they keep things in the same process unless you > mark it as forking off another. That way, if you know its safe it can be > alittle faster, and if its not, you can sand box it abit. Couldnt you do > the same thing with this problem? If you dont use pinvoke or you dont use > it very much then stay in process, if not, jump out to a new one for that > service. > > Bob > > On Thu, 21 Nov 2002, Kai Strempel wrote: > > > Hello, > > > > Mathias Hasselmann wrote... > > >>I'm also voting for the mono based service manager. Additionally to the > > >>compatibility issue I could imagine that we also would gain some > > >>efficience from using a mono based service manager: See the Mono runtime > > >>would be launched only once (potentially faster startup) and as long as > > >>not explicitly requested to deal it different all the services could > > >>life in appdomains of the same mono vm... > > > > putting all services in one SysV process is a bad idea. Because, if one > > hangs or crashed the hole mono::SCM is crushing. Appdomains are not the solution. > > For example if a p/invoke process crushed the appdomain has no change to > > recover this process. > > > > This weekend I will start to programm the System.Service namespace. > > > > Bye Kai... > > > > -- > > +++ GMX - Mail, Messaging & more http://www.gmx.net +++ > > NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen! > > > > > > _______________________________________________ > > Mono-list maillist - [EMAIL PROTECTED] > > http://lists.ximian.com/mailman/listinfo/mono-list > > > _______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
