Merge lp:~spiv/bzr/no-sigwinch-583941 into lp:bzr/2.1
| Status: | Merged |
|---|---|
| Approved by: | Andrew Bennetts on 2010-05-27 |
| Approved revision: | 4845 |
| Merged at revision: | 4844 |
| Proposed branch: | lp:~spiv/bzr/no-sigwinch-583941 |
| Merge into: | lp:bzr/2.1 |
| Diff against target: |
204 lines (+66/-40) 4 files modified
NEWS (+7/-1) bzrlib/osutils.py (+47/-35) bzrlib/tests/test_osutils.py (+12/-0) bzrlib/ui/text.py (+0/-4) |
| To merge this branch: | bzr merge lp:~spiv/bzr/no-sigwinch-583941 |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Vincent Ladeuil | 2010-05-27 | Approve on 2010-05-27 | |
| Martin Pool | 2010-05-27 | Pending | |
| Martin Packman | 2010-05-27 | Pending | |
|
Review via email:
|
|||
This proposal supersedes a proposal from 2010-05-26.
Commit Message
Remove the SIGWINCH handler to avoid EINTR problems. Instead poll the terminal size as needed. (#583941)
Description of the Change
Final, simple fix for EINTR?
This simply removes the SIGWINCH handler introduced in 2.1.0rc1, and adjusts the osutils.
I'm a little concerned that the logic inside terminal_width looks somewhat different now, because it tries _terminal_size before it tries $COLUMNS — but, strangely, the SIGWINCH handler had actually been setting $COLUMNS, so I don't think this is actually so different. And I do think the new code is clearer. I'd welcome second opinions though.
Finally, here's the diffstat to whet your appetite:
$ bzr diff | diffstat
NEWS | 8 +++++++-
bzrlib/osutils.py | 42 +++++++
bzrlib/ui/text.py | 4 ----
3 files changed, 16 insertions(+), 38 deletions(-)
As with the previous proposal for this, I've tested interactively that e.g. bzr log -n0 from a large HTTP branch continues successfully while the terminal is rapidly resized, unlike before.
| Robert Collins (lifeless) wrote : | # |
| Vincent Ladeuil (vila) wrote : | # |
>>>>> Andrew Bennetts <email address hidden> writes:
> Andrew Bennetts has proposed merging lp:~spiv/bzr/no-sigwinch-583941 into lp:bzr/2.1.
> Requested reviews:
> bzr-core (bzr-core)
> Related bugs:
> #583941 program crashes with "bzr: ERROR: socket.error: (4, 'Interrupted system call')"
> https:/
> Final, simple fix for EINTR?
> This simply removes the SIGWINCH handler introduced in 2.1.0rc1,
> and adjusts the osutils.
> I'm a little concerned that the logic inside terminal_width looks
> somewhat different now, because it tries _terminal_size before it
> tries $COLUMNS — but, strangely, the SIGWINCH handler had actually
> been setting $COLUMNS, so I don't think this is actually so
> different.
qblame to the rescue, have a look at 4747.4.3
(revid:<email address hidden>[1]):
,----
| * bzrlib/osutils.py:
| (terminal_width): COLUMNS takes priority on termios.TIOCGWINSZ as
| shown by tests under emacs (on no counter examples are known).
`----
This is indeed a known case where COLUMNS should take precedence. And
the comment you deleted was trying to hint at that. If you find a better
wording, please feel free to update it but don't just delete the hints
about the rationale.
Unfortunately, this couldn't be translated into a test since the tests
are supposed to be runned even without a controlling terminal ;(
We should check the env variable first *at least* when we start.
Now, if SIGWINCH occurs, we can't get an updated value for COLUMNS, so
we have to resort to _terminal_size (even if it's wrong now, it seems
less wrong than keeping a knowingly out-of-date COLUMNS) and setting
COLUMNS was the easiest way to go then.
[1]: Amazingly this revid includes the string 'bug' :)
| Martin Pool (mbp) wrote : | # |
That looks nice.
I'd like to check that running eg that log command does not take any longer with this patch.
I guess you can work out with vila what to do under emacs. I would guess that the ioctl just does not work there and so it's enough to use $COLUMNS if the ioctl fails, but it may be more complicated. Perhaps we can add a big comment about this.
| Andrew Bennetts (spiv) wrote : | # |
vila and I have had an extensive discussion on IRC. I'll try to write a comprehensive summary soon, but right now it's dinner time, so here's the short version:
1) I'll rework this patch for 2.1 to preserve the 2.1 behaviour as much as possible without using SIGWINCH (i.e. use COLUMNS until we observe the size from TIOCGWINSZ change), to minimise risk of regressions in 2.1.
2) I'll submit another patch for trunk that I think will be a better implementation of terminal_width: try $BZR_COLUMNS, then TIOCGWINSZ, then $COLUMNS in turn, until we find one that is set to a non-zero value. If none are set non-zero, return None. This patch will try to explicitly document the rationale and problematic cases to take into account, because the literature around determining terminal sizes is pretty confusing.
I'm popping this branch back to work-in-progress for now, but expect a resubmission soon.
| Martin Packman (gz) wrote : | # |
Looks good to me. There was a lot of detailed discussion on IRC about the specifics of getting the logic maximally compatible. Trying for a minimal change on 2.1 and investigating further for trunk sounds like a solid plan. So, this branch only really needs a tweak to make the initial result of _terminal_size weaker than COLUMNS before landing.
The question of speed has been raised a couple of times. Andrew timed _ioctl_
| Andrew Bennetts (spiv) wrote : | # |
Here's the patch to remove SIGWINCH with minimal behaviour change for 2.1. I've added some comments that try to explain some of the requirement and rationale that was unclear before.
| Martin Pool (mbp) wrote : | # |
urk, all this to measure what should be a history-independent property
of the environment.
Still, that looks clean and matches my understanding of the
discussion. Nice comment too. Perhaps you should wait until Vincent
gets to check it.
--
Martin <http://
| Andrew Bennetts (spiv) wrote : | # |
Martin Pool wrote:
> urk, all this to measure what should be a history-independent property
> of the environment.
Yes :(
> Still, that looks clean and matches my understanding of the
> discussion. Nice comment too. Perhaps you should wait until Vincent
> gets to check it.
I'll do that.
| Robert Collins (lifeless) wrote : | # |
Vincent, when you review it, if you're happy please *just land it* in 2.1 - so that I can release 2.1.2 tomorrow.
Cheers,
Rob
| Andrew Bennetts (spiv) wrote : | # |
btw, Martin P asked earlier:
> I'd like to check that running eg that log command does not take any longer with this patch.
I did some manual testing of "bzr log -r-100.. bzr.dev" (753 lines of output), and there's no noticeable difference. So that's good.
(As an aside, I notice that trunk is a little quicker than 2.1 on that task, hooray! About 320ms vs 340ms on my system.)
| Andrew Bennetts (spiv) wrote : | # |
sent to pqm by email

DoIt - love to get this behind us