[Bug]: Event handling with input in callback function #30419

Activity

1. QuLogic commented on Aug 13, 2025

   

   QuLogic

   on Aug 13, 2025

   Member

   More actions

   This works fine with Qt (other than an exception if you click twice before entering something, since you can't call input twice), so this seems to be a problem with the macosx backend specifically.
2. QuLogic

   added

   GUI: MacOSX

   on Aug 13, 2025
3. QuLogic commented on Aug 13, 2025

   

   QuLogic

   on Aug 13, 2025

   Member

   More actions

   Maybe @greglucas has some thoughts.
4. ljlamarche commented on Aug 13, 2025

   

   ljlamarche

   on Aug 13, 2025

   Author

   More actions

   Thank you for the tip! This does work as expected if I manually set a different backend. Adding this to the top of the script has served as an effective work-around.

   import matplotlib
   if matplotlib.get_backend() == 'macosx':
       matplotlib.use('tkagg')
   
5. greglucas commented on Aug 15, 2025

   

   greglucas

   on Aug 15, 2025

   Contributor

   More actions

   I'm guessing this has something to do with our call to stopWithEvent() when we override the input stream, but I'm not certain.

   matplotlib/src/_macosx.m

   Line 105 in be68dfe

   usingBlock: ^(NSNotification *notification) {stopWithEvent();}

   Maybe we need to have a different check on what came from stdin "if it was a sigint: stop entirely, otherwise pause/let go of control" or something like that.

   I did check back a few versions and this looks like it does work on 3.8.4, but not on 3.9.3, I didn't bisect it yet.
6. dstansby commented on Aug 20, 2025

   

   dstansby

   on Aug 20, 2025

   Member

   More actions

   This bisects back to 18909c7
7. iccir commented on Jul 5, 2026

   

   iccir

   on Jul 5, 2026

   Contributor

   More actions

   The problem is that we are using -[NSApplication run] from both wait_for_stdin() and show(). When we call -[NSApplication stop:] from stopWithEvent(), it will stop both -run calls.

   The documentation for -stop: is deceptive:

   If you call this method from an event handler running in your main run loop, the app object exits out of the run method, thereby returning control to the main() function. If you call this method from within a modal event loop, it will exit the modal loop instead of the main event loop.

   That seems to indicate that some degree of re-entrancy is supported, but that only applies to modal sessions.

   The implementation of -run and -stop are:

   Pseudocode for -run and -stop:

   - (void) run
   {
       _running = 1;
       
       if (!_calledFinishLaunching) {
           [self finishLaunching];
           _calledFinishLaunching = YES;
       }
   
       // A whole bunch of additional one-time initialization code
       
       while (_running) {
           NSEvent *event = [NSApp nextEventMatchingMask: NSEventMaskAny
                                               untilDate: [NSDate distantFuture]
                                                  inMode: NSDefaultRunLoopMode
                                                 dequeue: YES];
           
           [self sendEvent:event];
       }
   }
   
   - (void) stop:(id)sender
   {
       _running = 0;
   }

   Hence, once -stop: is called, all nested calls to -run will return since NSApplication's _running ivar is 0. Here's a vibe-coded example that demonstrates this:

   NestedRunTest.m

   #import <Cocoa/Cocoa.h>
   
   @interface AppDelegate : NSObject <NSApplicationDelegate> 
   @end
   
   
   @implementation AppDelegate {
       NSInteger _nestLevel;
   }
   
   
   - (void) applicationDidFinishLaunching:(NSNotification *)notification
   {
       NSLog(@"Outer run started, _nestLevel = %ld", (long)_nestLevel);
   
       [NSApp addObserver:self forKeyPath:@"running" options:NSKeyValueObservingOptionNew context:NULL];
   
       [self startEventPump];
   
       [self performSelector:@selector(nestRun) withObject:nil afterDelay:0.05];
   }
   
   
   - (void) startEventPump
   {
       NSTimer *timer = [NSTimer timerWithTimeInterval: 0.01
                                                target: self
                                              selector: @selector(pumpEvent:)
                                              userInfo: nil
                                               repeats: YES];
   
       [[NSRunLoop mainRunLoop] addTimer:timer forMode:NSRunLoopCommonModes];
   }
   
   
   - (void) pumpEvent: (NSTimer *) timer
   {
       NSEvent *event = [NSEvent otherEventWithType: NSEventTypeApplicationDefined
                                           location: NSZeroPoint
                                      modifierFlags: 0
                                          timestamp: 0
                                       windowNumber: 0
                                            context: nil
                                            subtype: 0
                                              data1: 0
                                              data2: 0];
   
       if (event) {
           [NSApp postEvent: event atStart: YES];
       }
   }
   
   
   - (void) observeValueForKeyPath: (NSString *) keyPath
                           ofObject: (id) object
                             change: (NSDictionary *) change
                            context: (void *) context
   {
       NSLog(@"running changed to %@", [change objectForKey: NSKeyValueChangeNewKey]);
   }
   
   
   - (void) nestRun
   {
       _nestLevel++;
   
       NSLog(@"Entering nested run at _nestLevel = %ld", (long) _nestLevel);
   
       if (_nestLevel < 3) {
           [self performSelector:@selector(nestRun) withObject:nil afterDelay:0.05];
       } else {
           [self performSelector:@selector(callStop) withObject:nil afterDelay:0.05];
       }
   
       [NSApp run];
   
       NSLog(@"Returned from nested run at _nestLevel = %ld, isRunning = %ld", (long)_nestLevel, (long)[NSApp isRunning]);
   
       _nestLevel--;
   }
   
   
   - (void) callStop
   {
       NSLog(@"Calling stop:, _nestLevel = %ld", (long)_nestLevel);
       [NSApp stop:nil];
   }
   
   @end
   
   
   int main(int argc, const char * argv[])
   {
       NSApplication *application = [NSApplication sharedApplication];
       AppDelegate *delegate = [[AppDelegate alloc] init];
   
       [application setDelegate:delegate];
       [application run];
   
       return 0;
   }
8. iccir

   added a commit that references this issue on Jul 5, 2026

   First pass at MPLEventLoop for matplotlib#30419

   8653dad
9. iccir commented on Jul 7, 2026

   

   iccir

   on Jul 7, 2026

   Last edited by iccir

   Contributor

   More actions

   I've been researching the history of #28981 for the past few days. First, no blame to anyone - NSRunLoop and friends are notoriously difficult. I had to review a bunch of code that I wrote 15 years ago :)

   ---

   Historically, wait_for_stdin was using -[NSApplication nextEventMatchingMask:…] with a date of -[NSDate distantPast] inside of a while loop. That was always going to result in heavy CPU utilization as the run loop wasn't being allowed to sleep and then wake itself up.

   This was changed to use -[NSApplication run]. That correctly loops with -[NSDate distantFuture] but has the side-effect of introducing this bug since re-entrant invocations to -run aren't supported.

   I do not understand the following comments at the top of wait_for_stdin():

   // Short circuit if no windows are active
   // Rely on Python's input handling to manage CPU usage

   There should be almost no CPU utilization when waiting for an event with an untilDate: of -[NSDate distantFuture]. The only thing that I can think of is that there was thrashing from constantly setting up and tearing down the NSFileHandle notification. There definitely was CPU usage prior to #28981, but that was due to the loop with -distantPast.

   Note that I'm uneasy about any type of "short circuit" once NSApplication has been instantiated - there's more parts of AppKit that need a running event loop even when windows aren't present. My best guess is that the constant churning of the run loop (prior to #28981) made everyone associate run loops with high CPU usage; hence, this check got added during development as a precaution.

   I'm still working on a solution that fixes both this while not regressing #26869 and #27515.