Closed Bug 31619 Opened 25 years ago Closed 25 years ago

thread safety nsIFileSpec

Categories

(MailNews Core :: Backend, defect, P3)

Product:
MailNews Core
Component:
Backend
Platform:
x86
Windows NT
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: dougt, Assigned: tonyr)

Details

tonyr@fbdesigns.com sent me an email regarding the thread safety of 
nsIFileStream. Currently this class is not thread safe and is asserting on 
addref/release.  I do not think that the right thing to do is merely remove the 
asserts, as they correctly point out a serious problem.  mscott, maybe you want 
to look at this.

From Tony's email:

----
Subject:  Threadsafe nsIFileStream?
   Date:  Sat, 11 Mar 2000 09:34:46 -0800
   From:  "Tony Robinson" <tonyr@fbdesigns.com>
     To:  <dougt@netscape.com>

Somehow, in mailnews after importing mail, an nsMsgFolder releases a
nsIFileSpec when mozilla quits that winds up releasing a stream and I hit
those great new threadsafe asserts.  Should I try and track down exactly why
this happens (could be lots of work!) or is it OK to fix up the
AddRef/Release in nsIFileStream.cpp?
---
OK.  If that class's AddRef/Release should not be made threadsafe then I need to 
find out exactly why I'm seeing this.
Assignee: mscott → tonyr
Duh... I was relying on nsIFileSpec to shut down any open streams when it was 
released but of course, the nsMsgFolder owned the file spec so it wouldn't get 
cleaned up till much much later.  A simple call to CloseStream from the import 
solved this problem.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
I checked this out and see the calls to CloseStream().

- rhp
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.