Hmm, from a quick look at the code, it seems this wouldn't start updating process. > probably OK to claim we do what is later found false (found corrupted). > that case? Index should just not lie about "not having something", but it's
#Download java plugin for firefox 41.0.2 on windows 7 update#
Also, if yes, should we do the index update for > corrupted, do we really start updating the index? Maybe yes, just want you
> Again, are you sure about this? If we find an entry (a file) that is It's actually worse than to just close them inĪgain, I'm comparing it with the current code, not with "leak everything" solution. > Are you sure about that? It means to: close the file, rename the file. Sure, but far less I/O than writing data and metadata. Calling close() in Linux doesn't flush the buffers and I guess that the same applies to Windows. writing all unwritten data and metadata). What exactly have you seen? I was talking about closing the file handle, not about cleanly closing the entry file (i.e. > On a busy and slow device easily one or more minutes? I've seen this. > (In reply to Michal Novotny (:michal) from comment #81) (In reply to Honza Bambas (:mayhemer) from comment #82) Sometimes being inaccurate is better than being slow. Also, if yes, should we do the index update for that case? Index should just not lie about "not having something", but it's probably OK to claim we do what is later found false (found corrupted). > corrupted entries on the disk intentionally we would need to update theĪgain, are you sure about this? If we find an entry (a file) that is corrupted, do we really start updating the index? Maybe yes, just want you to be 100% sure of that. > likely end up with an up-to-date cache index on the disk. It's actually worse than to just close them in inconsistent state. Dooming means to do I/O.Īre you sure about that? It means to: close the file, rename the file. Instead of leaking the data I wouldīut that doesn't solve anything. On a busy and slow device easily one or more minutes? I've seen this. > how long it could take to close 64 files even on a slow device? > forget that we cannot have more than 64 opened files at the same time, so > I don't think the problem is in closing the file on the system level. > close them all, already having bug 913822 for that. > (never close them) and let the system handle it when it takes too long to > One of my ideas for shutdown optimization was to simply let cache files leak > (In reply to Honza Bambas (:mayhemer) from comment #79) (In reply to Michal Novotny (:michal) from comment #81) I'm hoping :michal or :mayhemer can give us an answer (Can we have the cache service signal it's done with shutdown-maybe using some sort of main thread timer?- even if all pending cache writes aren't done yet?) But I'm not sure how easy that will be to implement.
Yes, I'd be fine with letting cache entries get corrupted so we could exit earlier (we detect corrupt entries and toss them next time they're used). > upon shutdown instead of waiting for all I/O events to happen > It seems to me like, given the nature of cache data, we should accept some data loss But I agree we shouldn't let this particular bug block shutdown. Well, in the general case with a priority scheme where lower priorities never get run if higher ones gobble all the time, you could make the case that the gobbler is the bug. This is a cache bug as far as I'm concerned.
> Really it should not be possible for addons or content to starve cache shutdown in the I assume the same is true for lowering Close event priority. In the general case of browsing we get significantly faster page load times by prioritizing cache hits (reads) over storing new cache entries (writes), which then get stored as things quiet down. > could you please comment on why the CLOSE event is a lower priority than other We don't have clear steps to reproduce and others have reported the problem without the Skype add-on installed, so I don't think it's fair to continue blocking it. If there was clear evidence that this add-on (the latest version in particular) is the culprit, rather than YouTube or other factors, I would keep the block up. > today is the kick-off of the big Firefox 42 marketing campaign. > Today is a particularly bad time to unblock Skype Click to Call because I don't have any stats on their version distribution to tell for sure. If the add-on is only installed or updated through their application installer, it's likely that many users would be stuck with older versions. It depends on how they handle automatic updates, if at all. > even if the add-on is not distributed through AMO? > Click to Call add-on? Shouldn't users have been receiving Skype updates, > Jorge, wouldn't we expect users to have the most recent version of the Skype
(In reply to Chris Peterson from comment #41)
0 kommentar(er)
