[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.]
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.
Marking INVALID for the reason stated above.