gh-153020: Fix race condition on event_tstate in _tkinter

[tangyuan0821]

event_tstate in Modules/_tkinter.c is read by the EventHook thread and
written by the main thread, so they race. I load and store it with atomic
ops, and clear it to NULL in DisableEventHook before the PyThreadState is
released.

• Issue: Data race on event_tstate in _tkinter.c under free-threading #153020

[ByteFlowing1337]

If the race is only possible in FT, why not use macros like FT_ATOMIC_LOAD_PTR or FT_ATOMIC_STORE_PTR to avoid the potential performance overhead in the default build?

[tangyuan0821]

If the race is only possible in FT, why not use macros like FT_ATOMIC_LOAD_PTR or FT_ATOMIC_STORE_PTR to avoid the potential performance overhead in the default build?

Good catch, switched to FT_ATOMIC_* since the race is only under free-threading. The default build just reads and writes it directly.

[ByteFlowing1337]

The suffix of the news entry filename looks incorrect. It should be a nonce generated by blurb, see https://devguide.python.org/getting-started/pull-request-lifecycle/#how-to-add-a-news-entry.

[ByteFlowing1337]

Suggested change

	Fix a data race in :mod:`!_tkinter` input event handling in free-threaded
	builds.
	Fix a data race in :mod:`!_tkinter` input event handling under the :term:`free-threaded build`.