On Fri, 13 Jun 2003, Just van Rossum wrote: > Kevin Jacobs wrote: > > > Also, this mechanism can *only* interrupt the main thread. (That's > > > even true of the more generalized version you were thinking of.) > > I wonder if that limitation would be liftable? Anybody interested in > persuing this with me? Sure! I've also got several complex applications to use as test cases that can be adapted to take advantage of threaded interrupts. > > Ah.. that sounds familiar. I knew there was a reason I didn't pursue > > this avenue farther last time I poked through that code. > > Same here. The code that checks for interrupts explicitly does nothing > when called from a thread that's not the main thread. That chunk of code is very problematic. Some platforms/threading libraries will deliver a SIGINT to all threads, which can abort many system calls that are not trivially restarted/restartable. To deliver a KeyboardInterrupt only to the main thread is problematic, since the other threads may misinterpret the failure as something else (EOF, fatal error, or worse, operation succeeded). I understand the desire to smooth over platform differences in Python, but I'm not sure that this one (signal delivery policy to threads) is a good idea. In fact, I'll try to find a real-world case where this kind of error occurs. > Naming: putting this into main sounds just right, but I would suggest to > call it sys.interrupt() instead of sys.interrupt_main(). That way *if* > we ever add the possibility to interrupt a non-main thread, > sys.interrupt() could grow an optional argument specifying the thread. I Agree. -Kevin -- -- Kevin Jacobs The OPAL Group - Enterprise Systems Architect Voice: (216) 986-0710 x 19 E-mail: jacobs@theopalgroup.com Fax: (216) 986-0714 WWW: http://www.theopalgroup.com
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4