Currently URLImpl uses NSPR cached monitors in order to be thread safe. The problem is NSPR cached monitors have a very large performance overhead. Kipp pointed out that NSPR 2.0 has simple locks, see PR_NewLock() which on Windows are just a critical section. We should have one NSPR lock for all of the URLImpl objects which makes the resource overhead low

rickg, would you consider this a ss: bug?

Taking off ss: list per bug mtg today.

Re-assigned to gagan@netscape.com. Gagan, is this a netlib bug? Who should get this?

I think that sounds feasible. Adding Warren for comments and accepting bug.

Noting [Perf] in summary. Starting to track bugs to review for performance milestone.

Setting all current Open/Normal to M4.

Moving [Perf] from Status to Status Whiteboard.

setting paulmac as QA contact for all gagan's bugs (sorry for the spam)

Per DP's suggestion marking these till M8. Though Necko lands with M7, we will be able to verify it for M8.

I'm moving this to target M9, Necko will be enabled somewhere during late M8 or early M9. We will need to get on this and it cannot be postponed past the M9 milestone.

Changing all Networking Library/Browser bugs to Networking-Core component for Browser. Occasionally, Bugzilla will burp and cause Verified bugs to reopen when I do this in a bulk change. If this happens, I will fix. ;-)

Probably not relevant with Necko. Pl. verify.

I don't believe that the URL methods need to be thread-safe now. The DOM and Netlib are no longer operating on the same object. Rick Potts should confirm this.

I'm resolving this bug because multiple threads are no longer sharing the same objects. It used to be that the underlying URL_Struct was manipulated by both the netlib thread and the UI thread. This is no longer the case... -- rick

Bulk move of all Networking-Core (to be deleted component) bugs to new Networking component.