Commit f9eb913
Avoid signal handling reentrancy issues
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.1 parent 42a686c commit f9eb913
1 file changed
+13
-6
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
95 | 95 | | |
96 | 96 | | |
97 | 97 | | |
98 | | - | |
99 | | - | |
| 98 | + | |
| 99 | + | |
100 | 100 | | |
101 | 101 | | |
102 | 102 | | |
| |||
728 | 728 | | |
729 | 729 | | |
730 | 730 | | |
731 | | - | |
| 731 | + | |
| 732 | + | |
| 733 | + | |
| 734 | + | |
| 735 | + | |
| 736 | + | |
| 737 | + | |
| 738 | + | |
| 739 | + | |
| 740 | + | |
732 | 741 | | |
733 | 742 | | |
734 | 743 | | |
735 | 744 | | |
736 | 745 | | |
737 | 746 | | |
738 | 747 | | |
739 | | - | |
740 | | - | |
741 | 748 | | |
742 | 749 | | |
743 | 750 | | |
744 | 751 | | |
745 | | - | |
| 752 | + | |
746 | 753 | | |
747 | 754 | | |
748 | 755 | | |
| |||
0 commit comments