CMapGeneratorWorker isn't thread-safe

[Philip Taylor]

CMapGeneratorWorker runs in a non-main thread but calls fs_util::GetPathnames and ScriptInterface::LoadGlobalScriptFile which aren't thread-safe. (Those are the only problematic ones I see currently.)

This results in assertion failures in debug mode for me, and it could crash if e.g. hotloading occurs while the generator thread is running that function. (I've added some extra assertions now to make it complain more immediately.)

Either VFS needs to be made thread-safe (which sounds very hard), or the generator needs to avoid calling those functions except on the main thread. Maybe Initialize() can read the script file into a string, and enumerate all maps/random/*/*.js and read those into strings too (there won't be loads so it should be fast enough), and then the generator thread passes any requested files into ScriptInterface as strings so it doesn't need to interact with the VFS again.

[ben]

(In [9261]) CMapGeneratorWorker thread safety issue. Fixes #783. VFS access moved to main thread, where random map scripts are preloaded and stored prior to use by the worker thread. Adds LoadGlobalScript to ScriptInterface, for evaluating script content in the global scope.

[Jan Wassenberg]

As discussed in the meeting, I don't see why VFS should be hard to make thread-safe. Wouldn't the proposed critical-section-in-each-VFS-routine solution safely handle this?

[Philip Taylor]

Yeah, I think now that probably should be sufficient.