ClapsOn2and4's picture

@ClapsOn2and4

Groups

    ClapsOn2and4's picture

    I really thought DispatchQueue would know how to do this by now (i.e. accept a concurrency param), but nope. Even still, I think I validated my theory with this one character change:

    diff --git a/compiler/VuoCompiler.cc b/compiler/VuoCompiler.cc
    index 6f281f04..2c7af1af 100644
    --- a/compiler/VuoCompiler.cc
    +++ b/compiler/VuoCompiler.cc
    @@ -1731,7 +1731,7 @@ set<dispatch_group_t> VuoCompiler::Environment::compileModulesFromSourceCode(con
                __block VuoModuleCompilationQueue::Item *queueItem = moduleCompilationQueue->next();
                VUserLog("Compiling %s", queueItem->moduleKey.c_str());
    
    -           dispatch_async(queue, ^{
    +           dispatch_sync(queue, ^{
                    try
                    {
                        VuoFileUtilities::makeDir(queueItem->cachedModulesPath);
    

    Of course this is not a good change because it blocks the main thread and makes startup take longer (much longer with lots of ISF modules); however with this change Vuo is stable with 1,236 ISF modules available...

    There's a little more info that might help you pinpoint the underlying problem: with this change, if there are unsupported ISF modules, I still crash sometimes after taking action in the dialog that is thrown about the unsupported module. Once the only modules being loaded are supported, it launches with no crash every time.

    Here's a screencap of the crashing with unsupported modules: https://youtu.be/kkrAhVJbeVg

    ClapsOn2and4's picture

    Hello,

    Please accept my humble +1 on this bug report. I've got huge piles of ISF files but I have to be pretty selective about which ones get loaded by Vuo or I get a crash shortly after launch. Several times I have methodically attempted a split-half search to identify the problematic ISF file(s), and I can confidently say that the behavior is non-deterministic. As you say, it's not a problem with specific ISF files, but rather with how many I try to load - seems like a race of some kind.

    I've attached a crash report, in which thread 84 is the crashed thread. I bet this problem could be mitigated (but not solved) just by capping the number of threads used to compile ISF files to the number of available cpu cores. Generally speaking, using lots of threads for this work makes sense as it's (probably) mostly I/O bound, but with more threads comes more opportunities to trip over any improper memory handling, etc. But you know all that :)

    Thanks a bunch! I'm a big fan of Vuo, and your small team does a great job interacting with the community.

    Cheers!