Allow app to track callback change

[Ten0]

This allows apps to answer the question "was I already called as part of handling this particular event?" from anywhere in the code, by tracking the callback counter.

In particular this is useful to simplify https://github.com/Ten0/homeassistant_python_typer/blob/1f8075ae6655a65aab093f20fa4624d6587a201b/README.md#what-to-be-careful-about

[acockburn]

Hi there - I took a look at this with a view to merging it in the next release as we discussed on discord, however I see a few issues with the code as it stands.

1. Unfortunately, as part of the massive Pydantic changes we just merged, there are now conflicts with this PR. Not a huge issue as it's fairly small, however:
2. The changes aren't thread safe. This would possibly get corrupted if 2 threads were running the same code concurrently (not usual but it can be configured that way) so it would need some kind of lock. Or, it might make more sense to move this counter to an attribute for the app's entity - they are all updated in AD's asynchronous core so wouldn't need locking for that reason.
3. The counter updates are present in async_worker() but not called in worker(), which means it would only work if the callback is an asynchronous callback

There is still time to get this into 4.5 if you want to take a crack at resolving the above issues - let me know if you have any questions, or jump into discord and shout me and we can discuss.

[Ten0]

Hey!
Thanks a lot for your time on this topic, and apologies for the delay here (a head trauma is slowing me down a little these days 😵‍💫).

The counter updates are present in async_worker() but not called in worker(), which means it would only work if the callback is an asynchronous callback

Unless I'm mistaken I was calling it in the version of your previous review: 9e31c9e#diff-1a121850c02feea540ea9012eb3fb5e99550e2ce5f654293b672d45144271079R1015

Were you referring to a different place?

The changes aren't thread safe. This would possibly get corrupted if 2 threads were running the same code concurrently (not usual but it can be configured that way) so it would need some kind of lock.

Ah I thought I was covered by the GIL on app.counter += 1. 😅
/me updates their understanding on how hard multi-threading in Python is
Is this ok?

Or, it might make more sense to move this counter to an attribute for the app's entity

I went for the approach of using the app's own lock. The state approach seems heavy (in particular on the reading end): The use-case is just:

def some_function(...):
	if app.callback_counter != self.last_seen_callback_counter:
		self.clear_some_caches()
		self.last_seen_callback_counter = app.callback_counter
	# Now process the things

Is that ok?

[acockburn]

Thanks for the update, and hope you feel better soon!

I’m traveling on business for the next few days but I’ll review this when I get home.

The plan is still to get this into 4.5!