If e.g. two SIGUSR1 signals arrive at almost the same time, it can be that the first one hasn't finished refreshing the UI yet when the second one needs to be handled, leading to a generator being executed twice, which python doesn't like.
We try to avoid this by scheduling the actual handling logic as a coroutine on the currently running event loop.
This has the advantage that the signal handler now has full access to any async functions or synchronization primitives.
As long as the event loop is single-threaded, the current version should avoid this particular crash as the refreshing logic is not async and hence cannot be interrupted at the event loop level.
If this were to change at some point, an asyncio.Semaphore or equivalent primitive can be easily introduced.
If e.g. two SIGUSR1 signals arrive at almost the same time, it can be that the first one hasn't finished refreshing the UI yet when the second one needs to be handled, leading to a generator being executed twice, which python doesn't like. We try to avoid this by scheduling the actual handling logic as a coroutine on the currently running event loop. This has the advantage that the signal handler now has full access to any async functions or synchronization primitives.
As long as the event loop is single-threaded, the current version should avoid this particular crash as the refreshing logic is not async and hence cannot be interrupted at the event loop level. If this were to change at some point, an asyncio.Semaphore or equivalent primitive can be easily introduced.