Vista Overlay Icons constantly appear/disappear

Issue #1 resolved
Anonymous created an issue

On a new vista install, I notice that the root folder of an Hg repository (That is the folder containing .hg) the overlay icons constantly appear/disappear. On a large repository it takes quite sometime to build the overlay, and as soon as it does they promptly disappear.

Comments (11)

  1. jrem

    On another computer running XP sp3 the same repository works fine. (noticed version .6 was a big improvement over 0.5.) On Vista just get a continual progress bar, brief display of overlay icons then progress bar starts again. Note that size of enclosing folder is approx 10GB, will try rearranging folders so just the version controlled files are tracked by Hg, see if that makes a difference.

  2. Steve Borho

    I was able to try this again with the tracelog dialog running. It seems Explorer is calling for TorotoiseHg to refresh the overlays over and over again. I didn't see any errors in the tracelog to indicate why it was doing this. I would like to fix this before 0.7, but I can't guarantee anything.

  3. Steve Borho

    Attached is a capture from tracelog while this "refresh" problem is going on. I used tortoisehg-crew so the repository structure is well known. What I suspect is happening:

    • TortoiseHG creates three overlay handlers, one each for Unchanged, Changed, and Added
    • The overlay handlers are separate python class instances, but they share a cache of the state of the most recent revisioned subdirectory.
    • Usually, Explorer will refresh the three overlays in series after each directory change and this caching scheme works quite well.
    • On Vista, there appears to be a timeout. If the first overlay doesn't answer soon enough, it asks the next one about the same file, and then the third one. See line 108 where this starts
    • I think the method TortoiseHg uses to query the status of a directory is actually recursive, but I need to verify this. I think this extra overhead is triggering the overlap in overlay updates.
    • So when updating a large-ish repository root, the overlays are all running at the same time trying to update the same global cache, thus the blinking.

    If this is truly multithreading the python callbacks, this is bad for a number of reasons (I don't think Mercurial dirstate operations are thread state, since it is updating a cache of it's own on disk). What I don't know is what this behavior looks like on XP, or whether the directory status query operation is actually recursive. I will investigate both of those today.

  4. Steve Borho

    Attached is a better dump. I backed out the change I made last night, which introduced a regression. This dump has the original behavior of the overlay cache, but with tweaks to the print statements to better understand what's going on.

    You can now see the progress of the three overlays refreshing themselves. And you can see them interfere with each other. You can also see how Vista refreshes the repo directory itself after refreshing it's contents. I suspect this might be what triggers the endless refresh loop, since the repository directory will usually have an 'unknown' status. This conflicts with what explorer knows about the directory contents so it starts over.

    So my latest thinking is there's two problems.

    1. the overlay threads are corrupting each other by updating the cache at the same time (see how they start out as unchanged and end up unknown on the second pas)
    2. the repo root status is always reported unknown, which causes repo root to be refreshed endlessly
  5. Steve Borho

    I spoke too soon. While I did fix the problem of the overlays disappearing, I didn't completely fix the constant refresh. It seems that this can still happen when viewing the repository root. I still think this is caused by the way we report status for the repository root (XP never asks).

    Unfortunately, it's too late to fix this for 0.7. It will have to wait for the next release.

  6. Steve Borho

    Overlay: ThreadingModel registry setting ID: 1895443

    It worries me a little bit that TortoiseHg sets the "ThreadingModel"="Both" in the registry for it's overlay handler COM component. "Both" implies that the component can handle free threaded calls (thus will synchronize calls by itself).

    I haven't connected any current problem to this, but I would suggest to use "ThreadingModel"="Apartment" which tells callers that free thread calls are not allowed, which seems safer to me, given that it appears to me that the TortoiseHg overlay handler code doesn't have any thread synchonisation. As I understand it, COM will synchronize the calls with this setting.

    I haven't identified explorer.exe to use multiple threads when calling the overlay. But might be good to stay on the save side with regards to the cache in iconoverlay.py.

    The attached patch would ensure that "ThreadingModel"="Apartment" in the registry.

  7. Log in to comment