> > Signals: just say no. It is impossible to write correct code in the > > presence of signals. > > Wrapping all I/O calls with PyOS_ wrappers would be a good start. And what should those wrappers do? > After that the wrappers can be modified to retry the call on EINTR. But that's not always what you want to happen! E.g. if an app is blocked on a read and uses an alarm to bail out of the read. > This should solve all the problems I have encountered with > interference to Python code by signals. Any other problems I should > be aware of? There's no way to sufficiently test a program that uses signals. The signal handler cannot touch *any* data, which makes it pretty useless. --Guido van Rossum (home page: http://www.python.org/~guido/)
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