I’m wondering how the gateways run tag event scripts. I may have a slightly intensive function I want to run on one of these events, when I’ve tested it using a timed gateway script it was about 10 seconds (its more like a minute when run on the client though). Does it use any other threads or do I need to use something like invokeAsynchronous? Of course, I’d really love to avoid bogging down the gateway when this runs.
Most stuff in the gateway runs in various flavors of ThreadPoolExecutors. You don’t want to hog a thread like that. A good rule of thumb for GUI events is to use invokeAsynchronous if the execution time is more than 1/10 second. In the gateway, you can be a bit more sloppy, but I’d ensure that the actual event was substantially faster than the scan time of the tag.
Consider using a Gateway Tag Change Event Script instead of a Tag Value Change Event. The former are documented to run in their own threads, and not overrun themselves, and can use project script modules. Far, far better than tag events.
5 Likes
I have a question regarding tag scanning/threading. I hope this is the right topic to post it.
If I have 10 tags, all in 1s scan class. Each tag has a script that runs on tag’s value changed event. Also, in script there is delay of 2 seconds (time.sleep(2)).
In above scenario if value of all tags is changed at same time, will valueChanged event of last tag be fired after 18 seconds (9 tags * 2 seconds delay)? My understanding is that all tags in same scan class are scanned from top to bottom something similar to PLC. Is this understanding correct or each tag runs parallel, independent of other tags?
Please explain. Thanks.
Tag events are not independent. It is not safe to use any form of sleep() (python or java) in any event script. Generally, the only safe use of sleep is inside a function started with system.util.invokeAsynchronous().
1 Like
Thank you @pturmel for your reply. So is the understanding that tags are scanned in sequential manner instead of all tags getting scanned at once (as per their scan class) is correct?
It’s an implementation detail, but IIRC there is parallelism across tag groups/scan classes, but sequential within, and all within a thread pool executor. So a single tag event that sleeps will likely hold up just the one group/scan class. But sleeping scattered across multiple groups/scan classes can block all tag execution.
Don’t sleep in any kind of event script. Don’t call long-running queries or calculations in event scripts. Any task that will take more than a tiny fraction of a second should be delegated to a background thread.
1 Like
Gateway Tag Change Script runs in separate thread as mentioned here. But did not find similar details for Client Tag Change Scripts.
Do Client Tag Change Scripts run in separate thread similar to their Gateway counterparts? And if they do, is it safe to use sleep or long running queries in these scripts?