On Sun, Aug 31, 2014 at 3:28 PM, Greg Ewing email@example.com wrote:
Victor Stinner wrote:
As written in the PEP, if you want to be notified of the signal, set a signal handler which raises an exception.
I'm not convinced that this covers all possible use cases. It might be all right if you have control over the signal handler, but what if you don't?
I think it's best if the functions in the os module remain thin wrappers that expose the OS functionality as fully and directly as possible. Anything else should be provided by higher-level facilities.
I'm inclined to agree about keeping the os module thin. If we were to recreate Python today, from scratch, it might make sense to hide this by default, but now there's almost certainly code out there that depends on the current behavior.
But I also agree that it's hard to pin down which higher level Python library calls are going to be using system calls. My http://stromberg.dnsalias.org/~strombrg/pypty/ program had a problem with window resizing for a while (SIGWINCH), and although I use it pretty much daily now without problems, I'm still not sure I got 100% of the possibilities covered.
Fortunately, wrapping a system call can be as simple as:
def retry_on_eintr(function, *args, **kw): ''' Retry a system call until one of the following happens: 1) It succeeds 2) It errors with something other than EINTR '''
while True: try: return function(*args, **kw) except OSError: nothing, extra, nothing2 = sys.exc_info() dummy = nothing dummy = nothing2 if extra.errno == errno.EINTR: continue else: raise
Note that os.read() and os.write() need different handling.