# Does the Tag Change Event work with a queue?

**URL:** <https://forum.inductiveautomation.com/t/does-the-tag-change-event-work-with-a-queue/98615>\
**Category:** Ignition\
**Tags:** ignition81\
**Created:** [November 14, 2024, 3:36pm UTC](https://forum.inductiveautomation.com/t/does-the-tag-change-event-work-with-a-queue/98615 "2024-11-14T15:36:03Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![danielps1818](https://avatars.discourse-cdn.com/v4/letter/d/ecae2f/32.png) [@danielps1818](https://forum.inductiveautomation.com/u/danielps1818)\
**Post date:** [November 14, 2024, 3:36pm UTC](https://forum.inductiveautomation.com/t/does-the-tag-change-event-work-with-a-queue/98615/1 "2024-11-14T15:36:03Z")

</div>

Hi!

I understand that the tag change detects all the events that change and saves them in a queue. Then every time the script executes, the next update waits for the script to finish and then the other execute.

Wanna know if this work like that and if there is any way of cleaning that queue.

_Context:_ My code has an event tag change that looks at some tags. Some of them can change independently but others could or could not change at the same time really fast. However, my script has a time.sleep(1) so if a lot of changes happend fast the code picks the last "stable" state. The things is even that the code wait and gets the correct state it gets execute 4 or 5 more times because of those fast updates, that's why I wanna remove those fast updates.

---

<div class="post-metadata">

**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:** [November 14, 2024, 3:37pm UTC](https://forum.inductiveautomation.com/t/does-the-tag-change-event-work-with-a-queue/98615/2 "2024-11-14T15:37:43Z")

</div>

No, you can't clear it, and you definitely should not be sleeping, blocking, or doing anything in general that executes slowly in your tag change event scripts - there is a shared thread pool responsible for executing these scripts and you will be blocking other tag change event scripts from executing in a timely manner.

---

<div class="post-metadata">

**Author:** ![danielps1818](https://avatars.discourse-cdn.com/v4/letter/d/ecae2f/32.png) [@danielps1818](https://forum.inductiveautomation.com/u/danielps1818)\
**Post date:** [November 14, 2024, 3:40pm UTC](https://forum.inductiveautomation.com/t/does-the-tag-change-event-work-with-a-queue/98615/3 "2024-11-14T15:40:57Z")

</div>

Are you telling me that if I do time.sleep(1000) in a lot of those script I could block all the tag change event? (not doing simply exaggerating the problem)

What If instead of calling directly a script I use `system.util.invokeAsynchronous()`. Could that work?

---

<div class="post-metadata">

**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:** [November 14, 2024, 3:42pm UTC](https://forum.inductiveautomation.com/t/does-the-tag-change-event-work-with-a-queue/98615/4 "2024-11-14T15:42:37Z")

</div>

> [@danielps1818](#):
>
> Are you telling me that if I do time.sleep(1000) in a lot of those script I could block all the tag change event? (not doing simply overexagerating the problem)

Yes, you really shouldn't do this.

> [@danielps1818](#):
>
> What If instead of calling directly a script I use `system.util.invokeAsynchronous()`. Could that work?

Yes, but now you risk creating many threads, and it's probably not the right answer.

You need to rethink what you're doing so that it doesn't involve sleeping or ordering between tags if possible.

---

<div class="post-metadata">

**Author:** ![danielps1818](https://avatars.discourse-cdn.com/v4/letter/d/ecae2f/32.png) [@danielps1818](https://forum.inductiveautomation.com/u/danielps1818)\
**Post date:** [November 14, 2024, 3:44pm UTC](https://forum.inductiveautomation.com/t/does-the-tag-change-event-work-with-a-queue/98615/5 "2024-11-14T15:44:28Z")

</div>

I'll do it.  
Thanks Kevin!

---

<div class="post-metadata">

**Author:** ![danielps1818](https://avatars.discourse-cdn.com/v4/letter/d/ecae2f/32.png) [@danielps1818](https://forum.inductiveautomation.com/u/danielps1818)\
**Post date:** [November 18, 2024, 2:05pm UTC](https://forum.inductiveautomation.com/t/does-the-tag-change-event-work-with-a-queue/98615/6 "2024-11-18T14:05:49Z")

</div>

We thought about it.

We can't call the script directly to not overload the tag events threads.  
Our aproach is to use `system.util.invokeAsynchronous` with a lock.

The first call is going to lock the thread, because the lock is used globally. Whenever another tag changes it's simply going to encounter the lock locked and exit the thread.

A simplified version:

```python
# [tag event change]
system.util.invokeAsynchronous(path.to.function.main)

```

```python
# [script]
import threading

def main():
	lock = global.Lock() # over simplified

	# if lock.locked():
	# return

	# lock.acquire() # we lock it

	if not lock.acquire(False): # @pturmel solution
		return

	# code to execute
	print "Hello world!"

	return

```

Even if we have more that one thread waiting at the lock.locked() the code won't break. And because we have a 1 second delay we can easily not have multiples thread waiting to be executed.

_Just posted to add to the forum. It's currently working fine ^^_

---

<div class="post-metadata">

**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:** [November 18, 2024, 2:22pm UTC](https://forum.inductiveautomation.com/t/does-the-tag-change-event-work-with-a-queue/98615/7 "2024-11-18T14:22:16Z")

</div>

> [@danielps1818](#):
>
> ```python
> if lock.locked():
> return
> 
> lock.acquire() # we lock it
> 
> ```

That is racy. You can get two threads executing the latter `.acquire()`. You should use this construct:

```python
	if not lock.acquire(False):
		return

```

That should be followed by a `try:` - `finally:` block to ensure the lock is released in spite of any errors.
