Implementing a stop button in AppDesigner

Currently, I have a run and stop button implemented in AppDesigner. When I click the run button, it runs another script on the PATH. When I click the stop button, I'd like it to find the running script and halt it from proceeding, whereever it currently is. Is there a way to track the PID of a .m script file currently running?

Answer 1

[Guillaume]

PIDs are used by the OS to track executables. m scripts don't have PIDS they're run within a matlab executable. Assuming the m script is run by a different matlab session as the one running your App, you could kill that separate matlab. Otherwise, no matlab does not let you kill scripts.

[Faker Mayfield]

So, is the solution to this spawning another instance of Matlab, keeping track of its pid, and killing it when pressing stop? That seems rather costly.

[Guillaume]

It's not clear from your original description whether the script runs in the same instance as the App. Since you were talking about PIDs, I assumed it wasn't.

If the script is simply launched from your app (with run) then depending on the script code it's possible your app wouldn't respond until the script is finished. Matlab is single threaded, so while it's busy running something it can't really do anything else.

There are various ways around that (e.g parallel toolbox) depending on what the script actually does.

[Faker Mayfield]

I'm running an exported AppDesigner app (.m file) filled with callbacks and other GUI goodness. When I click a button titled "run" it simply calls another .m file's main method. This currently executes successfully.

I added a pause(5) to test your theory of the app potentially freezing and that is not the behavior I am seeing. I'm still able to control the GUI and hit other callbacks while the main method stays paused.

Essentially, I'm hoping to stop that main method from executing no matter where it is when I press the stop button from the app.

[Guillaume]

I'm not sure what you mean by exported, or by main method.

Indeed pause would not freeze the app, it explicitly instructs matlab to do other things (such as App events). However, if you were running a very long calculation (e.g. ismember(rand(1e4), rand(1e4)) or maybe even a very long for loop) then I suspect you'll find your App unresponsive.

[Faker Mayfield]

Thanks for the responses!

In AppDesigner, there is an export button, which takes the .mlapp file and exports it to a .m file. By main method, I was referencing the start of my app that begins to kick off calculations.

Yes, it indeed becomes unresponsive when running long calculations, thanks for that point on pause. So, would running another instance of MATLAB in the background and communicating GUI responses via UDP/TCP resolve this or is the Parallel Computing Toolbox really the way to go?

[Guillaume]

If you have the parallel toolbox, it would be the easiest method. However, I can't help with that I don't have the toolbox.

Without the toolbox, my approach would be to modify the processing function so that it periodically checks if it needs to stop (and give a chance for the UI to process the events).

Otherwise, indeed you're left with implementing your own multithreading. Yair has written an excellent series on the different solutions. Starts at: Explicit multi threading - part 1 but for you, part 4 is probably the most relevant.

Answer 2

[jmore]

You can get around not having the parallel computing toolbox by adding a pause(0) (not sure how this works, but it does).

function stopSim(app, event)
    app.stop_sim = true;
end
while i<=100 && app.stop_sim == false
    pause(0);
    % do something until user pushes the stopSim button
end

Once the user pushes the stopSim button, for which function "stopSim" is a callback, then the app has enough time to fetch the updated propertie of the app, to app.stop_sim == true and hence it is able to terminate the while loop before reaching 100 iterations.