Error when executing MATLAB app methods via parfeval and BackgroundWorker pool.

I try to execute some method from my app asynchronously in the background. The goal is to be able to cancel it if it gets stuck and to execute suitable function-specific failure reaction.

        function MainFunc(app)
            %modify some local app properties and access external APIs
        end
        [...]
        % Button pushed function: StartExecButton
        function StartExecButtonPushed(app, event)
            %preparation
            FunHandle = parfeval(backgroundPool,@MainFunc,0,app);
            pause(3);
            if strcmp(FunHandle.State,'running')
                cancel(FunHandle);
                app.InfoTxt=[app.InfoTxt;{'WatchDog: Main Function took too long and was aborted.'}];
                app.TextArea.Value=app.InfoTxt;
            else
                cancel(FunHandle); %just as a safety measure
                if app.MainSuccess
                    app.InfoTxt=[app.InfoTxt;{'WatchDog: Main Function finished in time with success.'}];
                    app.TextArea.Value=app.InfoTxt;
                else
                    app.InfoTxt=[app.InfoTxt;{'WatchDog: Main Function finished in time without success.'}];
                    app.TextArea.Value=app.InfoTxt;
                end
            end
        end

When the function is called via parfeval I observe a failure message "parallel:threadpool:NonConcurrentLibrary / Use of library hg is not supported on a thread-based worker. Use alternatives supported on the background pool."

Does that mean that background pool is generally not useable with MATLAB apps, or am I just using it wrongly?

If usage with apps is not supported, is there any other parallel / concurrent execution framework that can be used with apps?

Answer 1

[Sean de Wolski]

MainFunc should be an external function you call and not an app class method. The app can update itself with the results of the main func computation. If you need this to happen while MainFunc is still running, you can use a DataQueue to pass the data back to the app client so it can self-update.

[Lionel Pöffel]

Thanks for the answer. It is not exactly what I was hoping for. Making asynchronous execution of app class methods with some access to the properties (if necessary via some additional lock mechanism) would be a huge improvement.

For my particular use case at least the simple approach via fetchOutput() seems to work. Using this will make a couple of things a lot more fiddly but not impossible.

[Sean de Wolski]

In a code review, I would flag any computation function that relies on the app or app properties. The computation model should be independent of the UI and not rely on its existenence. App designer code (i.e. code in the mlapp file) should ONLY be code for updating properties and dispatching to the computational model.

[Lionel Pöffel]

I fully get the comment. The particular use case in question has very little to do with actual computation and a lot with accessing external APIs that have the nasty habit of simply stalling the access instead of throwing exceptions if something goes wrong.

[Sean de Wolski]

You may want to consider using Stateflow for MATLAB to manage this. A simple state chart that transitions when the future either, finishes, errors, or it polls at some beat and can cancel it after a delay.

One example: https://www.mathworks.com/help/releases/R2021b/stateflow/ug/sf4ml-lamp-example.html

Answer 2

[Raymond Norris]

Do you have the Parallel Computing Toolbox? If so, try using a process-based pool (i.e., 'local') instead of a backgroundPool. For instance

p = gcp('nocreate');
if isempty(p)
    p = parpool('local',1);
end

FunHandle = parfeval(p,@MainFunc,0,app);

[Lionel Pöffel]

Does not seem to work. The MainFunc seems to be unable to access app properties.

Either I get failure messages à la "MATLAB:emptyObjectDotAssignment" although the app property in question gets assigned a non-empty value immediately prior to calling

FunHandle = parfeval(p,@MainFunc,0,app);

Or (if I comment out those assignments) the function still behaves as if certain other app properties had not been initialized properly (which, however, they have)