Ambal

Backport to 0.12 will come soon. Expect *nix TBB support to come first since dealing with Windows vcproj files isn't funny

Currently in code we do not use any specific features of Windows Vista/7, so yes, you can compile binaries in Windows XP and copy it to Vista/whatever and be happy

Yes, you compile mangos in usual way. You just need to copy those 2 new dlls into your mangos server folder

Then use these ones, lolz I can be mistaken in *nix libraries names

Copy libtbb.so.2 and libtbbmalloc.so.2 libs into your mangos folder and problem should go away

Well, these libraries auto-copy into output folder You just need to copy them further into you mangos folder And yes, if USE_STANDARD_MALLOC is defined, there is no need in them in mangos folder... Atleast for now since we are going to base all threading code on Intel TBB library in nearest future

Patch is in [8735]. Thanks to everyone involved in testings. Remember, you can always switch to default OS memory allocator just by using define USE_STANDARD_MALLOC while compiling 'framework' project!

Thanks for report, nanounico What about stability with new Intel TBB sources in 'rebase_branch'? Is it better or not? Do you still get crashes with memory allocator on your RHEL system? Like I said before, performance gains depend greatly on OS you use Because there are tons of different *nix OSes, some of which have very powerful standard memory allocator, thats why some of you, guys, do not notice any differences in performance P.S. You can compile mangos w/o Intel TBB memory allocator just by specifying USE_STANDARD_MALLOC define while compiling 'framework' project :rolleyes:

There is a bug in you code: you do not initialize bool m_deleted; in Runnable class constructor which means you can cause crashes and bugs yourself Also I hardly believe that this code can fix something =/

Quickfix for recent compilation issues in rebase_branch is removing Makefile from "../dep/tbb/" folder. There should be only Makefile.am Try and report ASAP. Update in GIT will come soon.

You can simplify check since pdamage is of type uint32: if(!pdamage || m_target->GetHealth() >= m_target->GetMaxHealth()) return;

Well, generally read-write locks are better, but only in scenarios where you can't avoid locking Also in case when you hold lock for very small amount of time there is no need for anything more complex than general lock

nanounico, is libtbbmalloc.so.2 didn't compile or it didn't copied correctly?

Intel TBB sources for 3.2.2 server got latest updates, 1st BugFix from Intel. Several important bugs and crashes are fixed! Please check 'rebase_branch' once again!

For those who want to get patch for 3.2.2 server, check "rebase_branch" in my repo

Check whether patch applied correctly in Database.h/.cpp - this affects greatly DB memory allocator usage. Also, could you test MemoryAllocator w/o any other custom patches to be sure that this particular one causes problems?

Provide a crashdumps and your system spec (OS type, version, compiler) please. P.S. I'm more than sure that those crashes with Intel TBB ver2.2 were caused by faulty patches =/

All we need is to be sure that this patch doesn't cause any problems with server logic :rolleyes: So 200-400 ppl online will be fine.

Boost is huge lib plus it contains only STL-containers memory allocator as far as I know. So no chance for it, sry :huh:

We do know about most critical in terms of performance MaNGOS systems and patches are on their way :rolleyes:

Well, ODBC is good but you get another layer of code which slows things down... We want MaNGOS to be compatible only with MySQL and PostgreSQL so there is no chance for ODBC to be implemented

It works across all CPUs with hardly noticeable performance advantages on Intel ones :rolleyes: As well as all code inside Intel Threading Building Blocks library

Stillhard, thats just a warnings, ignore them

Stability was ~5-6 hours. But it has improved dramatically since we've found the reasons why server crash so often with mtmaps patch... After that 14-16 hours uptime is normal

This patch has huge value to development team since it will allow less pain with multi-threading in a future so, please, test this one very hard