DOL @ Linux with Mono

[Lordy]

Hi, I was just looking for something to do and found my way back to DOL.
Well I saw its still not running with Mono thats why I downloaded the source and tryed it why not.

Its working now but I changed something I don't really understand
GameEventMgr.cs

Code: Select all

static GameEventMgr()
{
Lock = new ReaderWriterLockSlim(LockRecursionPolicy.SupportsRecursion);
m_gameObjectEventCollections = new Dictionary<object, DOLEventHandlerCollection>();
m_globalHandlerCollection = new DOLEventHandlerCollection();
}

The Problem is that part, LockRecursionPolicy.SupportsRecursion, thats not implemented into mono yet. I just removed it and I got dol to run on ubuntu.

I don't really understand the part what will happend if this part is just missing? Is there a way to replace it with somehting already implemented into mono?

[tobz]

It is required, unfortunately. An event notification could link to a callback that notifies for another event, thus requiring reentrance.

It might compile fine, and even run, but it *should* have that enum value.

[Lordy]

Got it working, I can run the server with ubuntu compiled with monodevelop (mono2.6) and running it with mono 2.8

[Graveen]

If you want to safely run DOL under mono, please check the pre 3.5 code.
ReaderWriterLockSlim() is a 3.5 feature not supported with mono.

Anyway, if you want to maintain a Mono compatible branch, feel free to be involved ! On our side, we can't afford this.

[Lordy]

Thats why I compiled mono 2.8, I want to run the current SVN, that there is no need for another branch.

Anyway, if you want to maintain a Mono compatible branch, feel free to be involved ! On our side, we can't afford this.

That I can't really understand. If DOL runs fine on Linux wouldn't it save a lot of money because you don't need to pay extra for Windows Server anymore?

[Graveen]

Yes.... but no. Here are the reasons:

* We don't want to restrict the technical usage. DOL was migrated to .NET 3.5 because of the benefits of ReaderWriterLockSlim(), but we were considering to do to simply use LINQ. IIRC the system status were also not working on DOL, same for colored logs in log4net. Reasons is DOL is also for us a nice way to improve our coding skills in some areas we rarely use (including new framework classes, but also 3rd party like OpenCL).
* Mono does not really scale as nicely as the native .NET framework, and we have some issues with performance or load management. The .NET VM is not really performant, and mono - at least with DOL - isn't running as fast (well, can i really say 'fast') as under Windows.
* Supporting Mono is something we don't really want. Of course, Linux users should generally perform best than Windows users, but we don't have the manpower to maintain 2 versions and ensure it'll run correctly.

So the money will be saved for the users, but certainly a nightmare for us (although we have Linux/Mono skills)

[Dunnerholl]

current svn runs with mono 2.10, as far as i can see without changes

[Graveen]

good to know, TY Dunn for the feedback !

[Blue]

My experience with mono back in 2005/2006:

- Way slower than .NET
- Uses more memory than .NET
- Garbage collection caused pauses of the whole server up to 1000ms

I don't know how much changed since then but I remember Hashtable implementation back in that time was more inefficient. Also the overhead for each object on heap was higher.

All in all it runs a lot smoother and lagfree on Windows/.NET. The lags from the garbage collector were a showstopper.

[tryagain]

Your experiences from 2005/2006 are hardly valid 5+ years later. There has been an amazing amount of work done. It might be worth a look again.

At any rate I just wanted to let anyone who was interested know that I'm tracking a Mono compatible branch here:

https://github.com/boscorillium/dawn-of-light/tree/mono

Master will stay in sync with SVN and then I'll merge changes to the mono branch. I have some other stuff I've started working on that I'll create a separate branch for soon.


cheers,

Tim

[Graveen]

Excellent work, Tim !

[Dinberg]

Fantastic Tim!

Grav, could we update the project info to include tims linux work?

[Graveen]

I'm shared. I think a new branch for mono is, mmmh, heavy, but i think the project is enough mature for a new target (debug, release, mono-debug, mono-release) with conditionnal compilation - mainly because it'll evolve continuously on the actual basis.

Code: Select all

[conditionnal("DEBUG")]
[conditionnal("RELEASE")]
public void MyMethod() { Console.WriteLine(".NET target"); }

[conditionnal("MONO")]
public void MyMethod() { Console.WriteLine("Mono target"); }

Really Tim, i'd enjoy if you can do this. Tell me if you think it is a good idea, i can open for you actual SVN for this purpose.

[tryagain]

Graveen,

I'm not sure that's the right approach. The changes right now are small, there are some explicit casts and MonoDevelop didn't like some of the warnings being suppressed (although I think it might be an encoding issue as the strings did not look correct but I just removed them instead of trying to figure them out at the moment).

I also don't like the idea of a conditional compile. A branch is nice (or in this case a separate github repo) because it will always work at tip for Mono. But if people are committing code to SVN without compiling it on Mono then there's a possibility it will be broken for Mono at some point at tip.

[Graveen]

With SVN, i always fear merges, and a conditionnal design will both avoid an unused branch and remember the contributers there is a mono support: mainly because the project is not as active, i fear your work could end with your support.

This is also because the changes are smalls than i suggest a new target: globally, the time should enhance the mono support, because mono will become more compliant. In fine, mono could easily be supported only due to mono itself, and the conditionnal compile will be removed as soon as some features are implemented.

In all cases, good job