Trying to get my head around the Task Cancellation Policy options

[handcoding]

I’m not new to programming, but I’m newish to webCoRE. I’ve read the wiki page for the Task Cancellation Policy options, and I’ve still got a few questions about how its options work if anyone might be able to chime in—

1. I gather that the Task Cancellation Policy only relevant to if statements and other conditionals (such as while loops and for loops)—is my understanding correct so far? (Or are there any nonconditional statements that could be affected by a Task Cancellation Policy?)

2. The wiki page for the Task Cancellation Policy implies that it only goes into effect if there’s a delay somewhere in the piston. Are wait or fade the only actions that can cause a delay within a piston, or are there also other actions that could fall into that category?

3. One of the options for the Task Cancellation Policy is “Cancel tasks on piston state change.” And as that goes—

• Let’s suppose that I’m hypothetically writing a piston to adjust my thermostat and that I’m manually setting the piston state to display the current temperature.
• And let’s suppose that the body of the piston is wrapped in an if statement that checks whether my Location is Home, and that that if statement is set to “Cancel tasks on piston state change.”
• In that scenario, does that mean that the entire piston would cancel itself as soon as I tried to set the piston’s state to “Thermostat set to 74°” or the like? (And if by any chance that might be the case, can I ask what a more legitimate use for the “Cancel tasks on piston state change” might be?)

I realize that this might be a lot of questions, and I really appreciate any insights on this!

[qoheleth]

1. You can also use it on With statements. (Basically it’s anywhere that you would want the block of code to execute regardless of state changes.)
2. It goes into effect most often with a wait or fade because they take some time. However, anytime a trigger event occurs, the piston starts execution at the top. If you don’t set TCP to never, some of that code may not execute.
3. Cancel tasks on piston state change works as you describe it. The only cases I can think that might be useful is 1) if you actually want to break execution as soon as you’ve set a state on the piston (There are better (at least more intuitively obvious) ways to do that though.) or 2) if you put in a wait and wanted it to abort that if the conditions change.

[WCmore]

One small tidbit to add:

Are wait or fade the only actions that can cause a delay within a piston, or are there also other actions that could fall into that category?

A semaphore delay can also cause the original trigger to return to being false

[handcoding]

Thanks so much for your help with this, @qoheleth and @WCmore! And if it wouldn’t be a bother, I had just a few follow-up questions—

You can also use it on With statements. (Basically it’s anywhere that you would want the block of code to execute regardless of state changes.)

Out of curiosity, if one were to set a with statement’s Task Cancellation Policy to, say, “on condition state,” what would that mean? That is to say, how would a with statement’s condition change if a with statement isn’t a conditional?

However, anytime a trigger event occurs, the piston starts execution at the top. If you don’t set TCP to never, some of that code may not execute.

From reading threads on the forum here, I seem to get the picture that setting if statements’ TCP to “Never” is sort of standard operating procedure for many piston authors? And if I might ask, why is that? Or to put it another way, if a given if statement’s condition isn’t changing, then why might a non-Never TCP end up prematurely cancelling the piston?

[WCmore]

Out of curiosity, if one were to set a with statement’s Task Cancellation Policy to, say, “on condition state,” what would that mean?

This is the default method. No manual changes are required to set TCP to “On condition state”

---

how would a with statement’s condition change if a with statement isn’t a conditional?

The WITH won’t/can’t change, but the IF holding the WITH can change, and cancel out the rest of the block

In other words, the IF condition/trigger fires up the WITH block. Normally, when the IF condition changes, the contained WITH will abort.

---

I seem to get the picture that setting if statements’ TCP to “Never” is sort of standard operating procedure for many piston authors?

It is rare that I use it. (maybe 10% of the time?)

However, it is often a solution posted here in the forum for pistons worded a certain way.

---

if a given if statement’s condition isn’t changing, then why might a non-Never TCP end up prematurely cancelling the piston?

I have never seen this before. Once a piston begins, it runs thru to completion, unless told otherwise.

[handcoding]

how would a with statement’s condition change if a with statement isn’t a conditional?

The WITH won’t/can’t change, but the IF holding the WITH can change, and cancel out the rest of the block

In other words, the IF condition/trigger fires up the WITH block. Normally, when the IF condition changes, the contained WITH will abort.

Your answers have already helped a lot, and I think I might just have one or two last questions, if that would be all right?

Let’s suppose that you had this pseudo-code:

IF 
    Location mode is Home
THEN
    WITH Dining Room Light
    DO
        Fade level to 100% in 5 minutes;
    END WITH
END IF

And let’s say that the if statement’s Task Cancellation Policy is set to “Never”, and the with block’s Task Cancellation Policy is set to “On condition state.”

• In that context, if I were to leave home before the 5 minutes were up, would that cancel the fade? (And for the sake of this question, let’s assume that it were actually possible for fades to be cancelled.)
• And if by any chance it wouldn’t make any difference if I were to leave home before the 5 minutes were up, is there another situation where the with block’s TCP of “On condition state” would make any difference if its parent if is set to “Never”?

[WCmore]

Let’s suppose that you had this pseudo-code:

IF 
    Location mode is Home
THEN
    WITH Dining Room Light
    DO
        Fade level to 100% in 5 minutes;
    END WITH
END IF

Sorry, but for all practical purposes, once begun, a fade cannot be cancelled.

For what it’s worth, I never set TCP on IF blocks. Only on WITH blocks.
(but feel free to experiment, and share your findings)

[handcoding]

For what it’s worth, I never set TCP on IF blocks. Only on WITH blocks.

That’s fair enough. And thanks again for chiming in about all this!