ID:1932185
 
(See the best response by Lummox JR.)
Hi, do DreamDaemon, can use more than one core?
I mean, if i got 2 cores, can they all work on hosting game?
Best response
Nope. It's limited to one core.
:O, that"s a big waste.
Short answer is no, you cannot use one DreamDaemon to utilize two cores. It is single-threaded.
There is also a longer answer, and an even longer answer, but that's the gist for most games.

EDIT: How to ninja with Lummox JR.
:-}
I understand, it"s hard to code 2+ core usage. I don"t have problem with that :-}
If there would be a easy way, to code 2+ cores usage. Byond owner would code it, but it"s a hard to do it, soo i understand it :-}
Also, thx for fast answer
It's more a problem that the bulk of the engine was written with single cores in mind, so for it to utilize multiple cores like it should, it would take a major rewrite of the code which just isn't that necessary right this second. Granted, multiple core processing would skyrocket some games in terms of efficiency and power, it's not the most major concern right now and the effort required to do so versus the importance of the issue is just so far unbalanced. Its just not worth it.
Some games would benefit from multiple server threads, but the majority wouldn't. The overhead of handling that turns out to be phenomenal, and even trying to separate server and client threads turned out to be nightmarish. But for multiple server threads to be possible, it'd be necessary to prevent simultaneous access to vars (or at least whole objects), and the checks and locks for that would add up quickly.
In response to Lummox JR
That's the problem I could see most people having with it. I mean, I don't think more than a few handfuls of vet developers here actually know how to use mutex's properly. Lol. It's not like they're very difficult, but unless you know ahead of time how threading works and the perils of it, a novice could quickly write something that breaks instantly.
In response to Kats
Kats wrote:
That's the problem I could see most people having with it. I mean, I don't think more than a few handfuls of vet developers here actually know how to use mutex's properly. Lol. It's not like they're very difficult, but unless you know ahead of time how threading works and the perils of it, a novice could quickly write something that breaks instantly.

It's not even so much that. If it was a matter of simply expecting users to use mutexes properly, it'd be easy enough to saddle them with the responsibility of using that properly. But the server has a lot of internal structures that can't survive concurrency. For instance if you try to read a var and write one at the same time on an object, you can have pointers break. Concurrent read/write to the appearance tree or the string tree would also be huge problems. Those kinds of things are pretty well impossible for Joe User to predict, so most of the mutex work would have to be done internally. (And even then, user mutexes would still be needed to avoid potential logic problems of the kind you described.)
In response to Lummox JR
I propose we come up with a new term for these things... I'm voting on Threadaches.