Comment 20 for bug 556829

Revision history for this message
In , Neil-httl (neil-httl) wrote :

(In reply to comment #18)
> (In reply to comment #17)
> > (From update of attachment 435225)
> > Although this obviously avoids removing the wrong folder, it doesn't actually
> > stop multiple attempts to check for status, and in fact would make it harder to
> > retrofit such a check.
> It does, by preventing duplicates from getting added to the array of folders to
> stat.
Sorry for being unclear, I was referring to multiple checks on the same server, rather than the same folder. (If you clicked Get Messages too many times, could you max out the cached connections?)

> > >+ // if we get an error running the url, it's better
> > >+ // not to chain the next url.
> > >+ if (NS_FAILED(exitCode))
> > >+ break;
> > What about the remaining folders?
> An error at this point is generally something that's not recoverable, e.g., the
> server is down, or we're shutting down. The remaining folders will still be in
> the array, so if we do STAT again, we'll get them on the next biff round.
So the idea is that because you won't add them again, you don't need to remove them?

> > >+ nsCOMPtr<nsIMsgImapMailFolder> folder = m_foldersToStat[folderCount - 1];
> > >+ m_foldersToStat.RemoveObjectAt(folderCount - 1);
> > >+ folder->UpdateStatus(this, nsnull);
> > Is UpdateStatus not always async?
> It is. I've changed m_foldersToStat to mean the folders still remaining to
> stat. Once we've started statting a folder, it is removed from the array.
I was just wondering whether you could write
m_foldersToStat[folderCount - 1]->UpdateStatus(this, nsnull);
or is that being too sneaky?