Heather Anderson

Heh, plus those asserts you got were just added yesterday; was suspecting this might be the underlying causes of the crashes (rather than just "misbehaviors").

Okay did some code re-ordering w.r.t. worker thread startup, assuming that these crashes are the first time through the loop. Less likely chance of this crash but no-crash doesn't mean...

okay dug into "exit code 6" and it looks like this crash basically happens the moment an assert() failure occurs. Still looks like we're having problems with new worker startup...

Okay new changes (as described in the commit): - New threads now unconditionally enter a wait without checking if numStarted==numThreads (as numThreads is changing out-of-band in this case. Yes it's...

Starting to think I may not know how condition_var.wait() works. Adding a mutex blocker to prevent the wait from occurring before all the threads have started up.

Yes, with all the stuff I've abandoned i've been thinking about this (specifically V8, as I have the most experience with this engine) Currently there is a single isolate generated...

I really hope so On Tue, Jul 26, 2022 at 9:43 PM stale[bot] ***@***.***> wrote: > Hello! Is this still an issue? > > — > Reply to this email...

Yah that was a bit confusing to me too. Everything I saw had it keyed to ownership challenges for objects though, which was square in the crosshairs of this PR....

MixerAvatar.cpp likely can be deleted as well. MixerAvatar.h is still in use and appears to have value (even though 90% of it has been removed)

Have rebased & squished the commits in this PR. Will compile/smoketest as well as remove MixerAvatar.cpp