> 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. I have never understood why a child dying should send a signal. You can poll for the child with waitpid() instead. But if you have a suggestion for how to fix this particular issue, I'd be happy to look it over, since this *is* something some people do. > 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). Yes. > 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. See above. I see half your point; people wanting this tend to use signals and it causes breakage. > > > 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. OK. > 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. Is calling the Python signal handler from the wrapper always safe? What if the Python signal handler e.g. closes the file or reads from it? --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