thread safety nsIFileSpec

VERIFIED FIXED

Status

P3
normal
VERIFIED FIXED
19 years ago
10 years ago

People

(Reporter: dougt, Assigned: tonyr)

Tracking

Trunk
x86
Windows NT

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

19 years ago
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?
---
(Assignee)

Comment 1

19 years ago
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
(Assignee)

Comment 2

19 years ago
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
Last Resolved: 19 years ago
Resolution: --- → FIXED

Comment 3

18 years ago
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.