Nice, I think this could simplify a lot of the objc code, and I think this PR should probably clean up while you are working on this. See here for a quick hammer to your linked issue that seems to still work as expected for me.5a30956
Feel free to take any or all of that yourself.

I also get the test failure timeout locally. If I click on the app icon to bring the window back into focus then the test passes. So, my guess is there is something with the event loop going to sleep and not being woken back up again?

Also just as a note since I was looking at this portion of the code here. I am pretty sure we've got some leaks in the window objects on the objc side (loop overplot(); show(); in memory_profiler and watch it build up) , and now that I'm seeing the retains in theWindowServerConnectionManager I'm wondering if some of that shared connection handling is keeping things alive and that would be worth looking at.

Thanks for the quick review. I just force-pushed a tiny cleanup for now as well as the change to the tests mentioned just above, I'll integrate your large cleanup patch later once we decide what to do with the problem below.

I can repro the failure on test_other_signal_before_sigint, with the same observation as you. Doing a bit of printf-debugging (e.g. adding a printf at the beginning of receivedData, and also a print in the _WaitForStringPopen.wait_for loop) suggests to me that there may(?) be a race condition between set_wakeup_fd and PyErr_CheckSignals: it seems like receivedData sometimes gets called before PyErr_CheckSignals will actually call a signal handler. Somewhat curiously, adding the printf also makes that test passsometimes, though not always, which supports the interpretation that there's a bit of delay needed before we can usefully call PyErr_CheckSignals (and the tiny delay from the printf helps making that call successful). Perhaps seepython/cpython#74224 as well.

If we can't figure that out quickly, I'd suggest just xfailing that test for now (perhaps on a shorter timeout...), as the behavior improvement on the plain test_sigint seems worth it by itself.

Interestingly, I have had a similar experience debugging some previous issues with the reference counting where I added in someNSLog() statements, and that miraculously fixed the segfaults I was trying to locate. I would agree though, if it isn't quick to find something reliable then xfailing seems reasonable, or just removing the macosx from this list of backends because we aren't testing anything other than qt currently anyways. Another thing to try would be to callflush_events() to try and spin the event loop on the objc side.

Calling flush_events (or rather inlining its implementation into receivedData) doesn't seem to help, so I've just removed the test for now.
I've also integrated your patch now, thanks for doing it.

Edit: turns out I can just register a block (a lambda) instead and completely kill off WindowServerConnectionManager.

Using mainQueue doesn't seem to help (but it may well be that it's indeed needed but not enough).
Perhaps we indeed need to repeat the wait but then I'm not sure why the printfs would sometimes help, and also I'd rather just defer implementing that to later (unless you see an easy way to do it).

No I don't see anything immediately obvious, my approval still stands, I was just throwing out ideas. It's just fine to leave that for later IMO.

Is the test failure unrelated? I haven't dug into this, but would be happy to merge on Greg's recommendation. Except the MacOS test is failing...

Closing and reopening to rerun tests with current main.

I'm pretty sure the test failure is the tk problems on azure that we were having for a while (and actually only skips still as we await azure fixing things on their end). Though the run is old enough to not be accessible anymore, so can't be fully sure.

Should be good to go from my perspective and CI is now passing, but note that there is some minor QT refactoring going on here as well.

@anntzer, this needs a rebase now.

Thanks for the bump, rebased.

Failing test is one of the newly added tests

Failing test is one of the newly added tests

I can confirm this test fails locally for me as well. It is only theshow +block=True combination that fails though which is odd. I think this combo can get skipped/xfailed for now with a comment indicating it is a known issue and if someone has time to investigate it then they can. But, this PR overall is a net gain and that can be saved for later IMO. My approval still stands.

I dug into this a bit more and it seems like theshow() version isn't starting the event loop right away, but instead sitting idly by and waiting for something else to wake it up. If you run the test and don't touch the mouse it fails, but if you move the mouse over the canvas that is enough to wake it up and trigger the events and make the test pass. So, I think we need to somehow explicitly start an event loop when we go throughshow().pause() explicitly callscanvas.start_event_loop(interval), which is why this test passes forpause().

I'll have limited access to a dev machine for a few days, so feel free to push an xfail for now or a fix.

Added the xfail for the show() + other signal case. At least from a quick look show(block=True) should call start_main_loop (via pyplot_show) so it's unclear why the event loop would not be started?