On Mon, Jan 18, 2010 at 7:04 PM, Adrian Buehlmann <adr...@cadifra.com> wrote: > On 19.01.2010 01:40, Steve Borho wrote: >> On Mon, Jan 18, 2010 at 6:20 PM, Adrian Buehlmann <adr...@cadifra.com> wrote: >>> On 18.01.2010 22:43, Steve Borho wrote: >>>> Since changeset dc0395b8dab6, overlay behavior on my development >>>> machines has improved substantially. I see a lot fewer instances of >>>> the overlays being out of sync with the working directory state. The >>>> few times when things have been out of sync, an F5 has always brought >>>> them together. >>> >>> That's interesting (see also [1] for reference). >>> >>> Or a bit frustrating, actually, because it means you must have hit >>> the time limit that starts causing to ignore overlay requests if >>> ::PathIsDirectory API calls are taking too long (we do a lot of these >>> when searching for .hg dirs, that's why I've set a limit on them). >>> >>> (Maybe I should remove that limit altogether. Sigh.) >> >> Perhaps, especially now that the web-dav strangeness has been resolved. >> >>> Is it possible to know a bit more about your setup? >>> >>> What Windows version is that and on what hardware? >>> >>> What kind of disk? NTFS/FAT? Local or network? >>> >>> What use case exactly? >> >> Before that change I saw out-of-sync overlays on all three of the >> machines I use on a daily basis, ranging from an old XP PC to a >> quad-core Vista x64 machine, which was the main reason I had ruled out >> that particular check. I didn't expect it to trigger on my newer >> machines and the skew seemed to always be worst on the quad-core. Not >> sure I can explain it except perhaps Vista and Win7 adds extra >> overhead to that particular function call. > > Vista and Win 7 started nailing us on multiple threads, which I haven't yet > decided whether this is a good idea or not. > > Under the assumption that slot handlers are independent, this might be a good > idea, but for usages like status icons of a VCS it is probably not. > > The overlay handler is not reentrant and thus has a crit section > right at the top of CShellExtOverlay::IsMemberOf. Maybe that could > cause some bad interlocking or something. > > I can't remember having seen those slowness errors in debug out > on my old crappy Win XP. I also can't remember having seen any signs > of multiple threads calling CShellExtOverlay::IsMemberOf ever. > >> I just assumed the badness was caused by my use of MQ and command line >> scripts, but it works a lot better now. >> >>> Can you post some debug out examples containing >>> >>> hasHgDir: PathIsDirectory .... in X ticks >>> >>> lines? >>> >>> What X values do you see? (typicals, largers?) >>> >>> What values Y do see on >>> >>> ****** .... call took too long (Y ticks) >>> >>> lines? >> >> I'll see if I can capture some. > > Thanks.
I installed 0.9.2 on my two home PCs (XP P4, Vista 64 AMD), but as soon as I enabled debugging and ran dbgview, I was unable to reproduce any misbehaviors. Not sure if that's evidence of anything other than this is a complicated problem. I'll keep my eyes on it and next time it starts acting up I'll try to get a good trace. -- Steve Borho ------------------------------------------------------------------------------ Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev _______________________________________________ Tortoisehg-develop mailing list Tortoisehg-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tortoisehg-develop
