[New Feature] MapUpdater/per thread

[Wowka321]

Opterman, and what about

World looking for players like all freeze. Nothing happen, nothing can't do Like big lag..but core don't stuck. U can teleport players by command from console.

? :confused:

[Opterman]

Just test it. World looking for players like all freeze. Nothing happen, nothing can't do Like big lag..but core don't stuck. U can teleport players by command from console. I did something wrong? :confused:

Its because map crashed maybe and server is logouting out players , i had a function that logout player sending them the client message and then logout them in the server but i souppoused that it was no need

But its needed maybe... Have you noticed i appears a backtrace message in cmd at this time¿

Or maybe you should change update interval

Anyway im going to do tests with a 2k + player server population

Greetings, Opterman

[XTZGZoReX]

1) Pool system per-map rewrite

2) Creature/GO per-map guid generation/use (stuck by (1))

3) proper locks for chat/group/guid/mail code

4) proper locks for global player list

5) Make per-map thread ready BG manager code

6) maybe something more

I plan to do number 3 and 5, possibly 4.

[freghar]

Otherwise your server would die from thread context switches

That highly depends on the CPU scheduler, with less than 200 threads, it should be pretty much fine on today's average machine. The switching overhead rises a bit somewhere around this "limit", but it's nothing really bad, 400 threads are like 400 processes (from the scheduler's point of view), which is roughly 10 processes per user for 40 users and many thin-client servers live with that. Moreover, the CFS scheduler is able to scale to even 4096 CPUs without much overhead, so the problem is rather theoretical on most modern OSes (I saw some improvements in this for BSD kernel + I guess that Windows server editions have thread management improved as well).

On the other hand, we really don't need this. To implement a thread-kill feature, we don't need to have a thread. Each of those threads processes some map - if we move this processing to a pool of threads, each thread will process more or less atomic pieces of the data. If an error occur, the current processing thread can either free all instance resources, causing the same effect as thread kill, or just schedule this task for another time.

And yes, I disagree with the "if something goes wrong, we need to segfault the server". There are many places where memory corruption may occur, but we should make sure that it isn't in the main process handling functions - ie. thread management. Even if it takes memory checksums (as I've seen elsewhere).

Separating each instance of a map to new thread wouldn't help us, since threads share memory addressing space. Thus you _can_ corrupt any piece of stack in the program from any thread.

.. just my 3 cents

[xeross155]

Once again, can someone clarify what they mean with a map-thread pool, having a fixed number of threads means you can only have a few maps running, or do you mean giving the thread a task from the map instead of making the thread be the entire map system.

[Woweur]

I will try your patch the next week with 2500 players

[XTZGZoReX]

Once again, can someone clarify what they mean with a map-thread pool, having a fixed number of threads means you can only have a few maps running, or do you mean giving the thread a task from the map instead of making the thread be the entire map system.

The thread pool has a number of threads that constantly run over a task list and check for new tasks. Each time it finds a new task, it then processes it. So no, it won't limit the amount of active maps in any way.

[Homenixx]

incredible work!

I will test it soon!

[Wowka321]

Don't know. Don't work for me on Windows

Players in world can't do anything. Allways big freez. World don't updating for players. Anybody try it ? :confused:

[xeross155]

The thread pool has a number of threads that constantly run over a task list and check for new tasks. Each time it finds a new task, it then processes it. So no, it won't limit the amount of active maps in any way.

Ah so instead of a 1 map per thread we just have 1 thread that assigns map tasks to the thread pools.

[Opterman]

Don't know. Don't work for me on Windows

Players in world can't do anything. Allways big freez. World don't updating for players. Anybody try it ? :confused:

Could u put server in Debug on VS and make an backtrace of MapRunnable's threads and WorldRunnable thread

What exactly occcurs ? Players cant cast ?

I've tested again on Windows last patch version with last core revision and works totally ok

Do you have another patch ?

Greetings, Opterman

[Derex]

Interesting approach, I really want to see some results on heavy load.

[Wowka321]

Could u put server in Debug on VS and make an backtrace of MapRunnable's threads and WorldRunnable thread

What exactly occcurs ? Players cant cast ?

Do you have another patch ?

Greetings, Opterman

On clear core. I test it by myself. You can't cast spells. You can move, but world arround you not updating. Mobs stay, u can't interract with world, can't chatting. But core working like normal. Like infinity big lag

I'll try to make BT on debug..

[darkstalker]

would be possible to make the effect of a crash local? like only disconnect the affected players/units and not the whole server. Fault tolerance on mangos would be very nice, i'm pretty sure blizz servers already have that.

[Opterman]

would be possible to make the effect of a crash local? like only disconnect the affected players/units and not the whole server. Fault tolerance on mangos would be very nice, i'm pretty sure blizz servers already have that.

Blizzard servers dont have it , blizzard server restart map if the error is on map and restart server if error is on network i can say it because i tested it my self....

Greetings, Opterman

[Woweur]

Just add StartUpdater(); in constructor of class Map and it's working. I will try the system for catch a crash

[Opterman]

Just add StartUpdater(); in constructor of class Map and it's working. I will try the system for catch a crash

I can't do this because when a map crash I dont delete the map instead this , I release all resources save all data and then restart the thread, so what you say is no possible.

Greetings, Opterman

[NetSky]

would be possible to make the effect of a crash local? like only disconnect the affected players/units and not the whole server. Fault tolerance on mangos would be very nice, i'm pretty sure blizz servers already have that.

blizzard is not using single servers this type of handling instance/bg crashes is kind of old fashioned(means it

has always there, as far as I can remember )

[XTZGZoReX]

When "map restart" happens it is in fact entire process, because they use one process per world map.

[VladimirMangos]

Nice catch with void Master::_OnSignal(int Signal) hooking BUT: such way of handling crashes is very dangerous, since we don't know what caused crash and simple 'restart thread and free map resources' technique is naive... I just fear that after some crashes we'll end up with infinite thread restarts :confused:

This not most bad end: most bad, end up with corrupted character data saved in DB. That why better crash and _prevent_ save corrupted data that prevent crash and save corrupt by bug data.

When "map restart" happens it is in fact entire process, because they use one process per world map.

And then safe for restart in same way as mangosd restart safe after crash.

[XTZGZoReX]

And then safe for restart in same way as mangosd restart safe after crash.

Yep, so Ambal is right - MultiMaNGOS is what you want for such a case.

[xeross155]

Well MultiMaNGOS has a long way to go, guess we'll have to wait or hop in and help em.

[Opterman]

This not most bad end: most bad, end up with corrupted character data saved in DB. That why better crash and _prevent_ save corrupted data that prevent crash and save corrupt by bug data.

And then safe for restart in same way as mangosd restart safe after crash.

Vladimir I thought that , it was the first thing that I thgought, but the only way to do the same thing of my patch and without mem corruption unsafe is process map by process , I think Multi Mangos will be the best option.

Anyway i 'll continue updating my patch and improving it , maybe I find another way to avoid memory corruption,i.e like someone say mem hashes checks

Greetings, Opterman

[XTZGZoReX]

Anyway i 'll continue updating my patch and improving it , maybe I find another way to avoid memory corruption,i.e like someone say mem hashes checks

You could also make wrapper classes for some platform-specific things, just make sure Unix, Mac, and Win supports it.

[Opterman]

You could also make wrapper classes for some platform-specific things, just make sure Unix, Mac, and Win supports it.

My patch is tested on Windows and linux , and it's what im going to do in next releases , at finish patch versions I'll test on Mac and switch it to this S.O. if doesnt work there.

Greetigns, Opterman