Hi everyone! I was experimenting with UniTasks and wanted to try to use UniTask.Run().
But UniTask.Run() crashes without any exception in WebGL. So I tried to enable WebGLThreadsSupport.
But now I have an issue when trying to build WebGL in 2020.1.2f1.
Everything builds if I use WebGLThreadsSupport: 0
I get error if I use WebGLThreadsSupport: 1
The error is:
Failed running “C:/Program Files/Unity/Hub/Editor/2020.1.2f1/Editor/Data/PlaybackEngines/WebGLSupport\BuildTools\Emscripten_Win\python\2.7.5.3_64bit\python.exe” -E “C:/Program Files/Unity/Hub/Editor/2020.1.2f1/Editor/Data/PlaybackEngines/WebGLSupport\BuildTools\Emscripten\emcc” @“C:\WorkProjects\DrViJ\PerfectCut\Assets..\Temp\emcc_arguments.resp”
Maybe somebody can tell what can be the reason of such error?
This is an unfortunate regression that stems from an internal LLVM compiler error after Unity multithreaded file IO codebase updated its use of atomics some time ago. We are working on patching up the whole compiler toolchain to a newer version. I believe the latest Unity version where the issue is not present will be the 2019.4 release branch.
@jukka_j Thank you for the update. It is much appreciated.
2020.1.0f is the latest version of Unity which works with WebGL threading enabled.
The challenge our team is facing is that 2020.1.0f was an initial release. The inability to create these builds in WebGL is a serious roadblock. There have been many subsequent releases with critical fixes since 2020.1.0f initially debuted.
Not wanting to complain, but also communicating that this is a major pain point for us. I think the official answer is “WebGL threading is unsupported”. That isn’t a great answer because this was a feature that was communicated and highly publicized to the world over two years ago. This is very much a hardship. Right now, we have a shippable product that is waiting on Unity to follow-through with their commitments.
using System.Collections;
using System.Collections.Generic;
using UnityEngine;
using UnityEditor;
public static class Initial
{
[InitializeOnLoadMethod]
public static void Init()
{
PlayerSettings.WebGL.threadsSupport = true;
}
}
Internal build system error. BuildProgram exited with code -2147024809.
System.ArgumentException: You're trying to copy to webgl/Build/webgl.framework.js more than once. Previously from Library/Bee/artifacts/WebGL/build/debug_WebGL_wasm/build.framework.js and now from Library/Bee/artifacts/WebGL/build/debug_WebGL_wasm/build.worker.framework.js
at Bee.Core.CopyTool.Setup(NPath target, NPath from)
at WebGLPlayerBuildProgram.WebGLPlayer.SetupCompression(NPath input, NPath output)
at WebGLPlayerBuildProgram.WebGLPlayer.SetupPostProcessBuildFile(NPath path)
at WebGLPlayerBuildProgram.WebGLPlayer.SetupPlayerExecutable()+MoveNext()
at System.Collections.Generic.LargeArrayBuilder`1.AddRange(IEnumerable`1 items)
at System.Collections.Generic.SparseArrayBuilder`1.ReserveOrAdd(IEnumerable`1 items)
at System.Linq.Enumerable.ConcatNIterator`1.LazyToArray()
at System.Linq.Enumerable.ConcatNIterator`1.ToArray()
at System.Linq.Enumerable.ToArray[TSource](IEnumerable`1 source)
at PlayerBuildProgramLibrary.PlayerBuildProgramBase.RunBuildProgram()
at PlayerBuildProgramTypeWrapper.Run(String[] args)
at Program.Main(String[] args)
UnityEngine.GUIUtility:ProcessEvent (int,intptr,bool&)
What’s the current state of this issue? @jukka_j@anthony_b
It’s already been 2 years since @stonstad reported it as an important blocker for his project.
I find this quite disturbing
I cancelled the WebGL version of the product and released to PC, iOS, and Android. WebGL would have been awesome, though.
Unity’s blog communicated that threading for WebGL was forthcoming and they did add an experimental version in 2019.1 ( https://discussions.unity.com/t/774290 ). A fully supported version never materialized and the team appears to be slow-playing things. I have not seen any recent updates from them, re: C# threading support and my question here and in another forum is unanswered.
I anticipate that this capability is blocked or will be replaced by the planned switch to .NET Core.
I imagine writing native javascript workers could be acceptable in some cases, but ofc, you’d just have to duplicate that logic. Might be worth it if there are just logs of calculations going on (I’m even imagining modelling the params and instructions of those calculations into a common type - basically a string which then you can parse on both C# and js, so that you can at least reduce some duplication).
However, and this might be the case for some people, I only needed support for async/await via the UniTask plugin, and [this]( https://discussions.unity.com/t/665972 page-2#post-8400342) plugin allowed me to do that without webgl threading (it’s basically all done on the main thread, scheduled via the regular Update)
