Plugin Action Execution Order?

Posted on
Fri Sep 16, 2011 1:14 am
Perry The Cynic offline
Posts: 836
Joined: Apr 07, 2008

Plugin Action Execution Order?

Here's an odd thing I've run into. Bear with me for a moment.

I have a custom device. The device has an action that increments a counter, and if that exceeds a threshold it fires a custom event trigger. I give Indigo a Trigger that, when that custom event fires, resets the counter. All that works just fine:
Code: Select all
  Action Group                    Increment Counter
  Cynical Explorer                Counter 10/10
  Cynical Explorer                Counter threshold trigger
  Trigger                         Counter Exceeded Threshold
  Cynical Explorer                Counter 0/10


Now let's change this action group so it performs the counter-incrementing action three times in a row. What could go wrong? Well...
Code: Select all
  Action Group                    Increment Counter Thrice
  Cynical Explorer                Counter 10/10
  Cynical Explorer                Counter threshold trigger
  Trigger                         Counter Exceeded Threshold
  Cynical Explorer                Counter 11/10
  Cynical Explorer                Counter threshold trigger
  Trigger                         Counter Exceeded Threshold
  Cynical Explorer                Counter 12/10
  Cynical Explorer                Counter threshold trigger
  Trigger                         Counter Exceeded Threshold
  Cynical Explorer                Counter 0/10
  Cynical Explorer                Counter 0/10
  Cynical Explorer                Counter 0/10

Even though the trigger fires each time, its action does not actually run until all three action-group actions have been done. So instead of the first action triggering the reset, and the second and third not triggering the threshold, we get three resets in a row at the end, and the counter ends up at zero instead of two. In other words, trigger actions for custom event triggers don't actually take effect when they're fired, but some time later.

Is Indigo meant to behave like that?

Cheers
-- perry

Posted on
Fri Sep 16, 2011 9:28 am
matt (support) offline
Site Admin
User avatar
Posts: 21411
Joined: Jan 27, 2003
Location: Texas

Re: Trigger actions delayed?

One of our sandboxing/stability rules for the Indigo Server is that it never (of course, there are exceptions :-) ) wait for a plugin process since the plugin might be hung up waiting for hardware, buggy, etc. This rule also helps reduce deadlock blocking scenarios (plugins can wait on the server, but the server never waits on plugins). The rule is followed when the server tells a plugin to execute an action. So when your 3 actions are executed, all 3 are queued up on the plugin side waiting to be executed while the server goes about its business:

Server -> Action increment counter
Server -> Action increment counter
Server -> Action increment counter

The plugin processes the first one, which trips your trigger and calls into the server:

Plugin -> Execute threshold trigger

Which then causes the server to add another action to the plugin's queue:

Server -> Action reset counter

But that action is queued after the original 3 actions (in the plugin host process). Therefore, the reset doesn't happen until those actions are complete (and counter gets up to 12). So the server's execution of plugin actions is asynchronous (it doesn't block) but on the plugin's side actions are executed sequentially (they are queued).

A possible workaround in your specific case would be to have the plugin reset the counter internally -- not via an Indigo trigger firing an action back into the plugin.

Image

Posted on
Sun Sep 18, 2011 1:57 am
Perry The Cynic offline
Posts: 836
Joined: Apr 07, 2008

Re: Plugin Action Execution Order?

A possible workaround in your specific case would be to have the plugin reset the counter internally -- not via an Indigo trigger firing an action back into the plugin.


Obviously - if I'm both the plugin writer and the Indigo user. Even in this fairly straight-forward example, we're bouncing from a user-defined action group to a plugin action, to a plugin trigger, to a user-defined trigger, and back to a plugin action. There's no way I can anticipate or deal with this in the plugin, since I have no idea what the user's going to do in Indigo.

I totally understand the queueing you're describing. I'm not so sure I want to explain it to users of my plugin. :-( But even with your queueing constraints, can't you process the pending action queue after each action of an action group has been completed? Do you have to run all actions of the group first? If you could "chop up" an action group and run its actions one at a time, the potential for getting out of sync would be vastly reduced...

Cheers
-- perry

Posted on
Sun Sep 18, 2011 10:48 am
matt (support) offline
Site Admin
User avatar
Posts: 21411
Joined: Jan 27, 2003
Location: Texas

Re: Plugin Action Execution Order?

Perry The Cynic wrote:
If you could "chop up" an action group and run its actions one at a time, the potential for getting out of sync would be vastly reduced...

But what it sounds like what you are describing is having the server wait for the actions to complete, which means having the server wait for the plugin (since it executes the action), right? That opens up the possibility of the server hanging on a rogue plugin (or frozen hardware the plugin is communicating with) or a plugin that is in a deadlock state waiting for the server or another plugin.

I'm not totally opposed to adding that option someday, but my point in the post above is it opens up a can of worms that we definitely don't want to tackle late in the v5 cycle (if ever). Specifically, it would require that the server have a timeout mechanism at which point it kills and restarts plugins if they don't respond or get into a deadlock. We do something similar for embedded python script execution currently, but that isn't something I want to add to the general action execution mechanism at this point.

The other option, besides the server waiting for the action call into the plugin to complete, is to just have the server delay the subsequent actions in the group a bit so that there is idle time between them where the server can process any call backs from the plugin (in this case the triggers). But I don't know how reliable that would be. The time would have to be carefully chosen so that it isn't long enough to make the action execution slow, but slow enough that the plugin has time to complete its calls back into the server. And if those calls end up creating new actions, then you can end up in a recursive situation which makes the delay between the actions at the root level need to be even higher to complete in time. So I'm not sure that is a good idea, since order execution then starts to become indeterministic based on CPU speed. With the current mechanism it may not be the order of execution you want, but at least it is consistently the same undesired order. :-)

Image

Page 1 of 1

Who is online

Users browsing this forum: No registered users and 3 guests