Dima Kuznetsov has posted comments on this change. Change subject: signals: Handle signals to non-main threads ......................................................................
Patch Set 15: (4 comments) Thanks for the review http://gerrit.ovirt.org/#/c/29392/15/lib/vdsm/sigutils.py File lib/vdsm/sigutils.py: Line 66: Line 67: _signal_poller = poller Line 68: _signal_read_fd = read_fd Line 69: Line 70: return _signal_poller > You don't want to return internal stuff like this. You're right, removing. Line 71: Line 72: Line 73: def wait_for_signal(timeout=None): Line 74: ''' Line 96: except select.error as e: Line 97: if e[0] == errno.EINTR: Line 98: interrupted = True Line 99: else: Line 100: logging.exception('Received error while waiting for signal') > Do we expect any error here? What if we get unexpected error in a loop? Agree about raising exceptions we do not expect to recover from, will change in next patch. About using: cleanup = _signal_poller.poll(timeout) I feel this is a bit too implicit, because that's not what poll() returns, and I'd rather have something like: cleanup = _signal_poller.poll(timeout) != [] Timeout part: I'd like to keep it, maybe one day we'll move this code into vdsm.infra and ship it as a library (along with zombiereaper and such). Line 101: Line 102: if events or interrupted: Line 103: _empty_pipe(_signal_read_fd) Line 104: Line 102: if events or interrupted: Line 103: _empty_pipe(_signal_read_fd) Line 104: Line 105: Line 106: def _read(fd, len): > Why put this before _empty_pipe? this is implementation detail of _empty_pi I do not believe there is right or wrong here Line 107: """ Line 108: Read that handles recoverable exceptions. Line 109: """ Line 110: while True: Line 123: try: Line 124: while len(_read(fd, 128)) == 128: Line 125: pass Line 126: except OSError: Line 127: logging.exception('Received error while reading from pipe') > Do we really want to log exception here? What errors are expected here? I agree about the first point, I'd not call these 'impossible' exceptions, because they can happen (for example someone decides to iterate all file-descriptors and close them, like in remoteFileHandler) but I agree they are not in our scope and we should raise these to the caller. The second point about not passing the file descriptor I am pretty ambivalent, I do not really mind changing it, but when the time of the year comes to change variable names in the file, there will be 2 extra places to rename :) About losing the while-loop, I am against it, because as unlikely as it might sound, I think it is simple enough to have it, and we won't have to count on avoiding unlikely situations. -- To view, visit http://gerrit.ovirt.org/29392 To unsubscribe, visit http://gerrit.ovirt.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: I5dbcd00cec22ef12f2b6253b016dcbd0aa889583 Gerrit-PatchSet: 15 Gerrit-Project: vdsm Gerrit-Branch: master Gerrit-Owner: Dima Kuznetsov <[email protected]> Gerrit-Reviewer: Dan Kenigsberg <[email protected]> Gerrit-Reviewer: Dima Kuznetsov <[email protected]> Gerrit-Reviewer: Nir Soffer <[email protected]> Gerrit-Reviewer: Saggi Mizrahi <[email protected]> Gerrit-Reviewer: Yaniv Bronhaim <[email protected]> Gerrit-Reviewer: Yeela Kaplan <[email protected]> Gerrit-Reviewer: [email protected] Gerrit-Reviewer: mooli tayer <[email protected]> Gerrit-Reviewer: oVirt Jenkins CI Server Gerrit-HasComments: Yes _______________________________________________ vdsm-patches mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/vdsm-patches
