How does Defold handle multithreading?

Muffin · May 23, 2020, 7:05pm

I couldn’t find anything on how Defold handles C++ threads in the documentation. If someone could point me to the right location I’d appreciate it.

I’m familiar with the web/browser model where you can pass some work from otherwise single threaded javascript to a javascript web worker which is doing its own thing off the main thread and can then pass things back. The main concept here being you write things like UI on main-thread and pass the rest on web worker if that is available.

But I’m quite new to the concept of Single threaded language passing instructions to a different multi-threaded language on anything but a “theoretical level” .

TLDR;
I’m looking for:

which tasks are relayed from Lua to be handled on the C++ side
does C++ side already use something like “thread detection” and spreads things that can be on different thread to available threads
simplified overview but for Defold tech architecture
If it is already using something like my “dream code for multi-threading” where you write asynchronous code with something like Lua coroutines and it then messages the C++ which spreads concurrent tasks on available threads

Pkeod · May 23, 2020, 7:35pm

If you write a native extension to do something you can have threads to do work. If you do need to do things which would block normal gameplay you should try to do it in NE threads, on some platforms like HTML5 this won’t help though because everything is forced single thread due to security requirements.

Otherwise Lua coroutines are not threads, there is nothing special done with that as far as I know. Would be cool if it was possible! Like ways to write async Lua containers that are run on their own actual threads so as to not block the main thread and can pass data as needed.

Some parts may be threaded but currently others like built in audio are not. You should generally assume things done in Lua are not threaded.

I think http.request() calls are threaded. Some resource loaded may be threaded but even with async set it can still lag your game, even audio will pause/glitch in some cases since it’s not threaded yet.

Of course the source is available now so you can read it yourself to see how it actually all works.

Something like the “simplified overview” to compliment https://defold.com/manuals/application-lifecycle/ would be cool to see.

github.com

defold/defold/blob/869a87718757bdb7bfd6ed078047fa7bfb451de9/engine/dlib/src/dlib/thread.h

// Copyright 2020 The Defold Foundation
// Licensed under the Defold License version 1.0 (the "License"); you may not use
// this file except in compliance with the License.
// 
// You may obtain a copy of the License, together with FAQs at
// https://www.defold.com/license
// 
// Unless required by applicable law or agreed to in writing, software distributed
// under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR
// CONDITIONS OF ANY KIND, either express or implied. See the License for the
// specific language governing permissions and limitations under the License.

#ifndef DM_THREAD_H
#define DM_THREAD_H

#include <stdint.h>

#if defined(__linux__) || defined(__MACH__) || defined(__EMSCRIPTEN__)
#include <pthread.h>
#include <limits.h>

This file has been truncated. show original

Mathias_Westerdahl · May 24, 2020, 9:14am

I actually was going to link to the documentation for the dmThread, only to find I still hadn’t added it to the SDK.
Added https://github.com/defold/defold/issues/4835 for this.

I like the idea of a more schematic overview of the engine, to help users/developers understand what’s going on under the hood.

Currently, there are only a few things that are threaded:
http requests, live update, some graphics requests (e.g. texture uploads),

Having the “UI on the main thread” mindset here is still valid, in our case it’s the Lua context that lives on the main thread, all callbacks need to be executed on the main thread.

We aim to do more threading though, it just hasn’t been too high on our road map.
I think first up on the list is to see if we can offload sound to a new thread, or perhaps resource loading.

dlannan · May 9, 2022, 7:19am

Sorry to resurrect an old thread, but I think my question fits in well here.

Im trying to use dmThread in an extension on Win10. And it appears the thread isnt really being created on another core - they appear to be getting creating on one core and thus just overloading the core.

Am I doing something stupid (highly likley) ?
All I am doing is dmThread new and then the thread runs for a short iteration (usually a loop of 300) and then it exits itself.

I keep track of how many Im running, and dont start any new threads unless I have free thread space to run more. I kinda expected each thread to be farmed out to a core. Should it ? Is there a need to use affinity on Win10 maybe?

Maybe Win10 threading isnt supported with dmThread?
Any help would be great. Thanks.

Mathias_Westerdahl · May 9, 2022, 7:22am

We’ll, I’m not saying you’re not right, but I just don’t see how it wouldn’t create a thread when we call CreateThread?

github.com

defold/defold/blob/dev/engine/dlib/src/dlib/thread.cpp#L170-L181

    
      
          Thread New(ThreadStart thread_start, uint32_t stack_size, void* arg, const char* name)
          {
              DWORD thread_id;
              HANDLE thread = CreateThread(NULL, stack_size,
                                           (LPTHREAD_START_ROUTINE) thread_start,
                                           arg, 0, &thread_id);
              assert(thread);
          
          
    SetThreadName((Thread)thread, name);
          
          
    return thread;
          }

dlannan · May 9, 2022, 7:27am

Nope ignore me. Something tragic with my code I think. It seems the threads are exiting faster than they can be created I think. Sorry for the confusion. Uggh!