Giving priority to a client tag thread?

Someone at my work wants to to try to put some of our Ignition business logic into client tag as handler functions essentially. Someone clicks a Submit type button, a dataset with the necessary info is sent to a dataset client tag, and the client tag is triggered on valueChange, reads the dataset, and inserts/updates the database. I did get this to work but the writes to the database are much slower than if we just had the database python script in the button function itself as we previously did, not to mention we can easily get confirmation from the database using a getKey=1 parameter.

He asked why it was slower and I estimated that it was because the script in the actionPerformed extension function of the button, given that it starts the whole process and the GUI is dependent on it, is the main thread that has priority in terms of ram and getting completed by Ignition, whereas the client tag with the valueChanged is running in the background on another thread, given lower priority/less processing power. But I’m not entirely sure that’s true. I’d also hazard a guess there was more overhead in terms of communicating from the client to the client tag to the gateway etc over just scripting directly.

Can someone explain how Ignition handles this situation? A extension function on a gui component runs, and in that script a client tag is written to that has a valueChanged event that is triggered. How does Ignition do these two processes - cocurrently? Does it finish the GUI extension function first? Lastly he wanted to know if there was a way to, in the middle of the GUI extenstion function, tell Ignition to focus on the client tag valueChange script/make it run faster in some way.

I know this is a not a specific question but we would like to know how Ignition handles this sort of situation under the hood and what if any ability to affect the process a designer has over it.

I realize I may have been unclear so what I really want to know is how Ignition handles this situation.

  1. GUI extension function runs
  2. GUI extenstion function writes to a client tag
  3. Client tag on valueChange extension function happens

Whats the order of execution and what ability to affect it does a designer have?

IIRC, the valueChange event will be queued up in a thread pool executor along with any other client tag operations. If you want equal priority to the GUI thread, just use a background thread started directly from your extension function. Put your business logic there. Don’t bother with a client tag unless it serves some additional purpose.

Ok so the GUI extension function runs to completion and then the queued up client tag change runs? And you’re saying use an invokeAsynchronously function to run in the backgroud if we want equal priority?

I’m personally against the whole idea anyways but was told to look into it.

Likely. I don’t recall which thread tag events on client tags run on. At least it’ll wait for its turn among other tag events. invokeAsynchronous() is certain to run its function at priority equal to the foreground.

You really should use a background thread. A long-running tag event will slow down/pause other tag events.

1 Like

Ok that’s all the information I need I think. Thanks.