# Best practices and pitfalls with Tag Event Scrips **URL:** \ **Category:** Ignition\ **Tags:** ignition81, scripting\ **Created:** [December 3, 2024, 10:29am UTC](https://forum.inductiveautomation.com/t/best-practices-and-pitfalls-with-tag-event-scrips/99355 "2024-12-03T10:29:29Z")\ **Posts on this page:** 1\ **Showing post:** 7
**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:** [January 13, 2025, 1:21pm UTC](https://forum.inductiveautomation.com/t/best-practices-and-pitfalls-with-tag-event-scrips/99355/7 "2025-01-13T13:21:39Z")
They don't take a thread from the three-thread pool used by the tag events subsystem, but borrow a thread from the tag subsystem itself, I think. (You could deliberately throw some exceptions in a callback to investigate the thread origin.) Use a gateway tag event script (in the project) for the heavy workload requirements. If there is some detail of the situation that requires they be tag valueChange events, consider this technique: > [@Java concurrent queue for tag change scripts](https://forum.inductiveautomation.com/t/java-concurrent-queue-for-tag-change-scripts/82044): > > Continuing the discussion from [[SOLVED] Are tag Value Changed scripts running asynchronously?](https://forum.inductiveautomation.com/t/solved-are-tag-value-changed-scripts-running-asynchronously/68704/5): We've got code in our standard library that I need to log a value change on a tag and then associate various data points with that value change. The value is located in a UDT, and because this is part of our "standard" library we use for our customers, the number of tags is variable and quite possibly numerous so having a gateway tag event script isn't feasible for this solution. I was reading up on … --- _[View the full topic](https://forum.inductiveautomation.com/t/best-practices-and-pitfalls-with-tag-event-scrips/99355)._