29950 - prevent concurrent writers of the newsrc file

Status: RESOLVED WONTFIX

(MailNews Core :: Backend, defect, P3)

Description

[(not reading, please use [e-mail] instead)]

this may not be a problem right now, but it may possible for us to corrupt the
newsrc file by having two concurrent callers of
nsNntpIncomingServer::WriteNewsrcFile()

I'm thinking ahead to when we have a nntp protocol cache, or mutliple three
panes, stand alone message window, etc.

this relates to the folder locking bugs #20548 #12850

Comment 1

[(not reading, please use [e-mail] instead)]

moving to m16.

Comment 2

[(not reading, please use [e-mail] instead)]

accepting.

Comment 3

[(not reading, please use [e-mail] instead)]

really accepting this time.

Comment 4

[selmer (gone)]

doesn't look critical to beta2, marking M18.  You should have a feature bug that 
depends on this...

Comment 5

[(not reading, please use [e-mail] instead)]

clearing milestone, m17 and m18 are meaningless now.  these need to be triages
along with the rest.

Comment 6

[(not reading, please use [e-mail] instead)]

sorry for the spam.  making bugzilla reflect reality as I'm not working on these bugs.  filter on FOOBARCHEESE to remove these in bulk.

Comment 7

[Serge Gautherie (:sgautherie)]

Filter on "Nobody_NScomTLD_20080620"

Comment 8

[Wayne Mery (:wsmwk)]

Joshua, can you imagine that this is still possible?

Comment 9

[Joshua Cranmer [:jcranmer]]

*chews on code for a while

So WriteNewsrcFile is called from three places:
1. The timer (which is initialized on, and therefore the callbacks executed on) the main thread.
2. CloseCachedConnections -- again only executed on the main thread.
3. CommitSubscribeChanges -- again, only on the main thread.

File I/O is synchronous, so no other events can run while we're writing the newsrc file--so it can only happen if we have multiple threads concurrently calling the function. That is so problematic for our code in general that it's no worse than the rest of the code.