# Behavior of Threads in Client Timer Event Script **URL:** \ **Category:** Ignition\ **Tags:** vision, scripting\ **Created:** [September 9, 2025, 12:00pm UTC](https://forum.inductiveautomation.com/t/behavior-of-threads-in-client-timer-event-script/110481 "2025-09-09T12:00:43Z")\ **Posts on this page:** 15\ **Page:** 1
**Author:** ![wingram](https://avatars.discourse-cdn.com/v4/letter/w/839c29/32.png) [@wingram](https://forum.inductiveautomation.com/u/wingram)\ **Post date:** [September 9, 2025, 12:00pm UTC](https://forum.inductiveautomation.com/t/behavior-of-threads-in-client-timer-event-script/110481/1 "2025-09-09T12:00:43Z")
I am currently working in a pretty archaic system, that is using a client event timer script at 50 ms to call the main() function in the scripting module. Currently there is no thread safety to this procedure and is leading to multiple race conditions, the main function calls 12 other scripting modules that provide separate functionality. I’m wanting to know what happens when the main() function is called from the client event script. For example, is the Scripting module being recompiled? Does the JVM kill the existing threads? Or do threads stack up in the background every time the main() function is called, and all processes aren’t completed? So far, I have noticed that local variables are re-initialized on each call, however, I’m not sure about if the threads are removed. For reference, it takes on average 40 s for a “real loop” to be finished, however, the script is running at 50 ms and the tags for the system are updated every 100 ms. My second question is that I am looking into using daemon threads for logging as it currently stands, logs are clogging up operation. Will calling the function again from the client event script garbage collect the daemon threads? ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [September 9, 2025, 12:39pm UTC](https://forum.inductiveautomation.com/t/behavior-of-threads-in-client-timer-event-script/110481/2 "2025-09-09T12:39:36Z")
> [@wingram](#): > > For example, is the Scripting module being recompiled? Does the JVM kill the existing threads? No, neither of these. > [@wingram](#): > > Or do threads stack up in the background every time the main() function is called, and all processes aren’t completed? No. The behavior depends on whether it's fixed delay or fixed rate, but: > [@Continuous running scripts](https://forum.inductiveautomation.com/t/continuous-running-scripts/104525/10): > > In "Fixed Delay", your script runs again at whatever the interval is _after_ the execution finishes. > > In "Fixed Rate", your script runs at the fixed interval, but if an execution goes long it does not overlap, the next execution just begins immediately after the previous finishes. Only one instance will be executing at any given time. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [September 9, 2025, 1:01pm UTC](https://forum.inductiveautomation.com/t/behavior-of-threads-in-client-timer-event-script/110481/3 "2025-09-09T13:01:34Z")
Sounds like there's a use of `system.util.invokeAsynchronous()`, if you really have multiples running together. ---
**Author:** ![wingram](https://avatars.discourse-cdn.com/v4/letter/w/839c29/32.png) [@wingram](https://forum.inductiveautomation.com/u/wingram)\ **Post date:** [September 9, 2025, 1:16pm UTC](https://forum.inductiveautomation.com/t/behavior-of-threads-in-client-timer-event-script/110481/4 "2025-09-09T13:16:27Z")
Okay that is perfect, it is running on a fixed delay with shared threading. If I’m understanding correctly no matter whether or not the script has finished it will be restarted from the top every 50 ms. Will this cause overlapping behavior? ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [September 9, 2025, 1:17pm UTC](https://forum.inductiveautomation.com/t/behavior-of-threads-in-client-timer-event-script/110481/5 "2025-09-09T13:17:43Z")
> [@wingram](#): > > If I’m understanding correctly no matter whether or not the script has finished it will be restarted from the top every 50 ms. Will this cause overlapping behavior? No, you're not understanding. The script will run to completion, however long that takes, and then will start again immediately if "however long" was longer than 50ms. ---
**Author:** ![wingram](https://avatars.discourse-cdn.com/v4/letter/w/839c29/32.png) [@wingram](https://forum.inductiveautomation.com/u/wingram)\ **Post date:** [September 9, 2025, 1:19pm UTC](https://forum.inductiveautomation.com/t/behavior-of-threads-in-client-timer-event-script/110481/6 "2025-09-09T13:19:26Z")
I think this would work well with some of the background functions, thank you! ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [September 9, 2025, 1:20pm UTC](https://forum.inductiveautomation.com/t/behavior-of-threads-in-client-timer-event-script/110481/7 "2025-09-09T13:20:31Z")
> [@wingram](#): > > fixed delay with shared threading This means that there will be a 50ms pause in between runs, no matter how long it ran, and all other shared threading timers will also not run when it is running. ---
**Author:** ![wingram](https://avatars.discourse-cdn.com/v4/letter/w/839c29/32.png) [@wingram](https://forum.inductiveautomation.com/u/wingram)\ **Post date:** [September 9, 2025, 1:21pm UTC](https://forum.inductiveautomation.com/t/behavior-of-threads-in-client-timer-event-script/110481/8 "2025-09-09T13:21:23Z")
Okay, that makes sense. ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [September 9, 2025, 1:21pm UTC](https://forum.inductiveautomation.com/t/behavior-of-threads-in-client-timer-event-script/110481/9 "2025-09-09T13:21:38Z")
Oh, yeah, I read that as "fixed rate" for some reason. So: the script will run to completion, however long that takes, and then will start again 50ms after completion. ---
**Author:** ![wingram](https://avatars.discourse-cdn.com/v4/letter/w/839c29/32.png) [@wingram](https://forum.inductiveautomation.com/u/wingram)\ **Post date:** [September 9, 2025, 1:21pm UTC](https://forum.inductiveautomation.com/t/behavior-of-threads-in-client-timer-event-script/110481/10 "2025-09-09T13:21:57Z")
Perfect, thank you! ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [September 9, 2025, 1:23pm UTC](https://forum.inductiveautomation.com/t/behavior-of-threads-in-client-timer-event-script/110481/11 "2025-09-09T13:23:51Z")
I would caution against adding invokeAsync and new Threads. You may have lucked your way into inheriting something that is slow but "safe" right now. If you start spawning new threads and speed up the main script you may actually end up in a situation where you start to accumulate slow running async threads and run yourself out of memory or just experience inconsistent behavior / race conditions. Without significantly more info it's hard to say. ---
**Author:** ![wingram](https://avatars.discourse-cdn.com/v4/letter/w/839c29/32.png) [@wingram](https://forum.inductiveautomation.com/u/wingram)\ **Post date:** [September 9, 2025, 1:25pm UTC](https://forum.inductiveautomation.com/t/behavior-of-threads-in-client-timer-event-script/110481/12 "2025-09-09T13:25:47Z")
I wouldn’t say it is “safe” right now mostly due to overlapping DB queries sniping data from each other. I might be looking for some mutex functionality to make sure things happen in order. On each call of the client event script do the local variables of the Scripting module reset or do they persist? ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [September 9, 2025, 1:26pm UTC](https://forum.inductiveautomation.com/t/behavior-of-threads-in-client-timer-event-script/110481/13 "2025-09-09T13:26:06Z")
> [@Kevin.Herron](#): > > caution Yeah, there be dragons. The task must be doing waits for various things in a procedural sense. It needs to be analyzed and redesigned to operate in an event driven manner (typically as a state machine), so that all events run without blocking. (Handful of millis at a time.) ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [September 9, 2025, 1:26pm UTC](https://forum.inductiveautomation.com/t/behavior-of-threads-in-client-timer-event-script/110481/14 "2025-09-09T13:26:43Z")
> [@wingram](#): > > local variables of the Scripting module Persist. Anywhere you might be getting simultaneous access needs locking (for your algorithms). Unlike CPython, Jython is fundamentally multi-threaded. Basic building blocks like dictionaries and lists are thread-safe, but algorithms built with them typically are not. ---
**Author:** ![wingram](https://avatars.discourse-cdn.com/v4/letter/w/839c29/32.png) [@wingram](https://forum.inductiveautomation.com/u/wingram)\ **Post date:** [September 9, 2025, 1:31pm UTC](https://forum.inductiveautomation.com/t/behavior-of-threads-in-client-timer-event-script/110481/15 "2025-09-09T13:31:46Z")
Thank you, I’ll be able to work with this.