[Bug 4887] New: New: hg diff uninterruptible until directory walk is complete

[mercurial-bugs at selenic.com]

https://bz.mercurial-scm.org/show_bug.cgi?id=4887

            Bug ID: 4887
           Summary: New: hg diff uninterruptible until directory walk
                       is      complete
           Product: Mercurial
           Version: stable branch
          Hardware: PC
               URL: http://mercurial-1.blogspot.com
                OS: Windows
            Status: UNCONFIRMED
          Severity: feature
          Priority: wish
         Component: share
          Assignee: bugzilla at selenic.com
          Reporter: charlieloveeric3 at gmail.com
                CC: mercurial-devel at selenic.com

f I have a repo where it's slow to stat all its files (large repo over NFS,
for instance, or on a local device where the cache hasn't warmed up yet), then
if I hit ^C while it's doing the tree walk for hg diff (or other similar
commands), it doesn't return to the shell until it finishes that walk.

Getting a stack trace at the moment the process gets the SIGINT shows that it's
hitting in walk() in dirstate.py, and more precisely, in the util.statfiles()
call it makes.  If the Python interpreter is refusing to do anything with
handled signals while it's executing in C extensions and this directory walk
takes a long time, then this would match the observed behavior.

I naively tried wrapping the lstat() call in Py_{BEGIN,END}_ALLOW_THREADS, but
since there's no threading going on here, it didn't have any effect.  I guess
it doesn't tell the interpreter it can handle signals in addition to releasing
the GIL.

Perhaps temporarily replacing the SIGINT handler would work?  But I'm not sure
about the safety of doing that.  The only other solution I can think of would
be to run smaller batches of lstat()s at a time, perhaps by making statfiles()
a Python function that called a C back-end that statted, say, a thousand files
per call or returned after a fixed amount of time.

This is on Solaris.  I wouldn't expect the behavior to be any different on
another OS, but perhaps I'm making a bad assumption somewhere.

--
You are receiving this mail because:
You are on the CC list for the bug.

-- 
You are receiving this mail because:
You are on the CC list for the bug.