429728 - XPCOMGC: rework nsHTTPConnectionHandle so it's not finalizer-dependent

Status: NEW

(Core :: Networking: HTTP, defect, P5)

Description

[Benjamin Smedberg]

Currently in necko, nsHTTPConnectionHandle is used to keep track of "open" connections. The final release of the object will cause the connection to be reclaimed with with the connection manager.

http://mxr.mozilla.org/mozilla/source/netwerk/protocol/http/src/nsHttpConnectionMgr.h#165

This doesn't work so well in XPCOMGC: because objects are not early-finalized, we need some other way to track when a connection is "finished" so that the count of currently open connections (per-host and total) is managed correctly.

I don't know exactly what this means... for the moment I just bumped the prefs so that I don't run into the connection limits, which at least gets me through more of the necko unit tests without livelocking.

Comment 1

[Benjamin Smedberg]

I have a "working" patch for this here: http://hg.mozilla.org/users/bsmedberg_mozilla.com/xpcomgc-patches/index.cgi/file/d03021664afc/http-connection-reclamation

This patch avoids finalizer badness, but doesn't deal with the "fact" that connection reclamation doesn't happen until GC runs. I think we really want client code to explicitly finish connections when they are no longer useful, if possible, but I'm not sure who the "clients" are in this case or how intrusive that kind of change would be.

Comment 2

[Christian :Biesinger (don't email me, ping me on IRC)]

bah, that's why I hate GC

Comment 3

[Patrick McManus [:mcmanus]]

connection handle hasn't been XPCOMGCFinalizedObject for a very long time.. is this wontfix? it certainly is ref counted though...

Comment 4

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258