Add features stopOnExit and waitFunctionStart and waitFunctionStop to scripts

[ldebs]

The purpose of this feature is to add waitFunctionStart and waitFunctionStop commands that are used to synchronize the execution of functions.

The start and stop signals are used by the commands to wait for the function to start or to complete before continuing the script execution.

The waitFunctionStart command causes the script to wait until a function with the given ID starts running. The script will continuously poll the function's state until it is determined that the function has started. Once the function is found to be running, the script will resume execution from where it left off.

Similarly, the waitFunctionStop command causes the script to wait until a function with the given ID stops running. The script will continuously poll the function's state until it is determined that the function has stopped. Once the function is found to be stopped, the script will resume execution from where it left off.

Example usage:

• QLC v4:

  waitfunctionstart:2 // Wait for function 2 to start
  waitfunctionstop:0 // Wait for function 0 to stop
  startfunction:3 // Start function 3

• QLC v5:

  Engine.waitFunctionStart(2); // Wait for function 2 to start
  Engine.waitFunctionStop(0); // Wait for function 0 to stop
  Engine.startFunction(3); // Start function 3

In this script, the function 3 is started only if function has started and function 0 has stopped after function 0 as started.

---

The pull request #1573 has been merged to this one

The stopOnExit feature introduces a new script command: stoponexit.

The purpose of this command is to control whether functions started during the script should be stopped at the end. When stoponexit is set to true, all functions started afterward will be stopped when the script finishes. By default, stoponexit is true.

Example usage:

• QLC v4:

  
  startfunction:1

stoponexit:false startfunction:2

stoponexit:true startfunction:3

stoponexit:false startfunction:4

* QLC v5:

Engine.startFunction(1);

Engine.stopOnExit(false); Engine.startFunction(2);

Engine.stopOnExit(true); Engine.startFunction(3);

Engine.stopOnExit(false); Engine.startFunction(4);

In this script, functions 1 and 3 will be stopped at the end, but functions 2 and 4 will continue running.

[ldebs]

Manually tested on v4 and v5 and working fine

[mcallegari]

Hi, a few comments:

• please don't mix pull requests. It's a bad practice and lead to confusion
• no need for polling the function status (which is very inefficient). The Doc class has signals for function running/stopped
• this feature is very risky and can lead to Script hanging while waiting for external triggers. You need to be 100% sure the Script can be killed at any time and doesn't consume CPU for no reason.

[coveralls]

coverage: 32.01% (-0.02%) from 32.034% when pulling a0be78653ab7d8e535344770afa39173542f348f on ldebs:waitFunction into c1f5846de11931e43213afbd49b7cbac1031e23d on mcallegari:master.

[ldebs]

* please don't mix pull requests. It's a bad practice and lead to confusion

As this pull request needs and include the #1573 one, I closed the #1573.

* no need for polling the function status (which is very inefficient). The Doc class has signals for function running/stopped

I can't find the signals running/stopped handling in the Doc class.

For v4 (Script class), as I implemented it, there is no such things as polling the function status, except for the first execution of the waitFunction commands and I just call the running() or stopped() methods of the function that just return the internal field value. The write loop exits because the waiting() function return false because the m_waitFunction is not NULL. the value of m_waitFuntion is set to NULL when one of the function signals is received.

* this feature is very risky and can lead to Script hanging while waiting for external triggers. You need to be 100% sure the Script can be killed at any time and doesn't consume CPU for no reason.

The implementation has the same behavior as the wait command. The write loop is interruptible in the same way. 100% sure !

I adapted the v5 (ScriptRunner class) to handle signals like the v4 version and thus consume less CPU during the write loop.

Please, let me know how to handle running/stopped signals through Doc class