Ger Luijten added the comment: Hello Roger,
To you and others that worked on this bug a big thanks for the extra deep dig into the chain of events to find this old bug and fix it. Impressive! Because I'm not familiar with the inner workings that cause this bug I was wondering if the kill command you use is the structural solution or just a clever workarond to prevent the error being written to the text widget and forcing the program to stop abruptly. For me your explanation raised the question if other processes that should terminate normally are now prevented from doing so and for instance are not able to do clear allocated memory (garbage collection). Could you shed some light on your bug fix? Greetings, Ger 2013/4/1 Roger Serwy <rep...@bugs.python.org> > > Roger Serwy added the comment: > > I found the root cause of the original error. > > Entering "exit()" at the shell raises SystemExit which gets written to the > shell's text widget. The call to actually write the text passes through > .write() in Lib/idlelib/OutputWindow.py, which calls text.update(). The > call to .update() enters the Tk event loop and flushes pending events, > including expired .after callbacks. > > Forcing the .after callback in .close() to 1 ms will always trigger the > error. Commenting out the text.update() in OutputWindow.py avoids the error. > > The patch causes .kill_subprocess() to execute immediately which prevents > the subprocess from writing to sys.stderr. > > ---------- > > _______________________________________ > Python tracker <rep...@bugs.python.org> > <http://bugs.python.org/issue5492> > _______________________________________ > ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue5492> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
