Investigating Unity hang on second run (multi-threading)
Unity hanging on the second Play press is a classic symptom with many causes — usually background threads. A walkthrough of my debugging process so you can diagnose your own hang.
8 articles in the notebook
Unity hanging on the second Play press is a classic symptom with many causes — usually background threads. A walkthrough of my debugging process so you can diagnose your own hang.
"Cross-thread operation not valid" explained from the ground up: what the GUI thread actually does, why only it may touch your controls, and how to cross over correctly in WinForms and WPF.
I hoped WPF had left WinForms' GUI-thread invoking behind. Then BindingList and DependencyProperty both demanded GUI thread invocation from my ViewModel — which isn't supposed to know the GUI exists. ARGH.
Tired of Invoke-ing the GUI thread from every background thread, I ran Reflector on WinForms' Form, generated a partial class with a Perl script, and got a Form where every method safely invokes the GUI thread automatically. A quick hack, but it works.
A deep dive into user space threading for .NET: why OpenSim needs to pause, serialize and resume thousands of running scripts, and the whole arsenal — from Mono.Cecil IL rewriting to fibers — I have thrown at the problem.
Script events now execute multithreaded — one object at a time, so multicore CPUs finally get used — plus cached event binding to avoid reflection on every call.
Builtin commands are easy — incoming events need planning. An EventHandler translates OpenSim happenings into LSL-compatible events, and an Event Queue Manager executes them on a separate thread so the server never blocks.
Running thousands of scripts on a grid cannot mean one OS thread per script. Old ideas come to the rescue: cooperative multitasking à la Windows 3.11 and NT fibres, i.e. user space threading where each script carries its own execution state.