If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

macsockotpt.c: OT notifier should listen for the kOTProviderWillClose message

RESOLVED INVALID

Status

NSPR
NSPR
P3
normal
RESOLVED INVALID
17 years ago
17 years ago

People

(Reporter: Simon Fraser, Assigned: gordon)

Tracking

4.0.2
PowerPC
Mac System 8.5

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

17 years ago
[Spawned from bug 66508, also related to bug 56170]

The Mac network code currently has some logic to deal with the situation where we 
try to call OTRcv on an endpoint which has been closed. As part of this logic, we 
set the orderlyDisconnect when we get an orderly release, and test that to 
determine how we'll respond to a later OTRcv.

I think a cleaner solution would be to listen for the kOTProviderWillClose 
message in the notifier. This gets sent in situations where the connection will 
be lost due to an interruption of networking, for example on PowerBook sleep. We 
may also want to listen for kOTProviderIsClosed. These additional notifications 
may also get sent on PPP disconnects, and handling them should make the network 
code more robust to lost connections.

[This bug applies to the NSPR being used by the Mozilla tip. Sorry, I don't know 
what NSPR version it is.]
(Assignee)

Comment 1

17 years ago
We do handle kOTProviderWillClose and kOTProviderIsClosed for the DNSNotifier 
routine, but I'm not sure of the utility of handling them in the general 
notifier.

In the DNS case, we use a single provider for all NSPR DNS lookups (Necko has a 
separate provider for handling async lookups), so we need to know when the 
provider has gone away so we can create a new one.

In the socket IO case, the providers are more transient; we wouldn't be able to 
create a new provider.  Also, the notifications arrive late, so we couldn't 
depend on getting them before attempting IO on a provider; we have to handle IO 
errors without the notifications anyway.

Updated

17 years ago
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → 4.2
Version: other → 4.0.2
(Assignee)

Comment 2

17 years ago
Marking INVALID for the reason stated above.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.