I’m doing a board game and I need multi thread for playing vs computer part.
Having a quick try, I see it works on Windows and my Android phone but not on the website.
1 Like
No, we currently use Emscripten 2.x which doesn’t have pthread support.
And while we strive to update to Emscripten 3, it will be also need to be a runtime check I believe, as not all browsers will support the feature.
What we do in the engine is to have two code paths, one for multi threading, and one for no threads.
When we use no threads, we instead rely on an Update() pattern.
Here’s a quick outline of how we do it:
struct MyContext {
dmThread::Thread m_Thread;
};
static void UpdateSingleFrame(MyContext* ctx) {
// do stuff
}
static void MyThread(void* ctx) {
while (true) {
UpdateSingleFrame(ctx);
}
}
void MySystemInit(MyContext* c) {
ctx->m_Thread = 0;
#if defined(HAS_MULTITHREAD_SUPPORT)
ctx->m_Thread = dmThread::New(MyThread, 0x80000, ctx, "mysystem");
#endif
}
void MySystemUpdate(MyContext* ctx) {
if (!ctx->m_Thread)
UpdateSingleFrame(ctx);
}
For an actual reference, see our sound.cpp.
2 Likes
HTML5 has web workers but maybe it’s a different part…
Is there a proper way to check if the platform supports multithread? It seems the HAS_MULTITHREAD_SUPPORT doesn’t work 
An additional question, is dmScript callbacks working on HTML5? I don’t see it’s called neither 
Exciting to hear that multi-threaded HTML5 builds may be considered in the coming months/years.
Threads and atomics are supported in all major browsers according to this chart - but I think they’ve only included desktop browsers. Mobile support is likely lagging behind.
Threads on the web also require a specific hosting setup with the correct headers set. Thankfully hosts like Itch and Newgrounds have already done the groundwork to enable this setup. There are also work-arounds using service workers.
It sounds like there’s no way around building the engine twice: once with threads enabled, and once without. This is because Emscripten warns “It is not possible to build one binary that would be able to leverage multithreading when available and fall back to single threaded when not.”. Web.dev also suggests this approach, and loading a separate module depending on the outcome of feature detection.
I’m curious how Defold plans to handle this detail. Will you automatically build the engine twice and load the correct module with logic in dmLoader.js? Or will you give end-users the option to build with threads or without, and leave the loading logic to us?
Examples of prior art: the Godot game engine used to have separate export options for HTML5 builds with threads, and without. However in their current 4.x branch, web support is more forward-looking and they only allow exporting with threads.
For security reasons, browsers have locked down on how SharedArrayBuffer works, meaning pages that use it can’t load third party content without that content having the appropriate settings. For example, at the moment if SharedArrayBuffer is enabled on a page, embedded YouTube videos won’t work on that page.
For the same reason, monetization through ADS is impossible for many portals if SharedArrayBuffer is enabled.
1 Like
Is this issue just a caveat to be aware of, or will it prevent the Defold team from enabling multi-threaded HTML5 builds indefinitely?
I’m always curious about what gets prioritized for Defold’s roadmap and why. 
The ads issue is something to be aware of, as it affects many of our users when it comes to monetizations.
It shouldn’t prevent us from adding support for threads.
As for how to implement it, we don’t yet exactly know what options we have.
First step is to upgrade the Emscripten version, then investigate our options.
I think it may be likely that (as you say) will have an option to opt-in for other features, and generally we do that with our app manifest, which allows us to choose what libraries to use and how to link the executable.
2 Likes