On Wed, Sep 04, 2002 at 09:25:01AM -0400, Guido van Rossum wrote: > > 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. If I use a module that spawns an external process and uses SIGCHLD to be informed of its termination why should my innocent code that just reads lines from a file suddenly break? In C I can at least restart the operation after an EINTR but file.readline cannot even be properly restarted because the buffering and file position is all messed up. The example you gave of bailing out of a read with a signal can be done using other techniques such as non-blocking I/O (which is, IMHO, a much cleaner way to do it). Getting an notification of a child process terminating or other asynchronous events can only be done using signals and is currently dangerous because it will break code using I/O. > > 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. In order to be useful a signal handler needs to be able to set one bit. The next time the ticker expires this bit will be checked. If an I/O operation was interrupted the Python signal handler can be executed immediately from the wrapper. When it returns the wrapper will resume the interrupted operation. Oren I/O, I/O, it's off to work we go... The seven dwarfs
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