This PRMonitor use might be dangerous, a holdover from Java days, rpotts said. Please ask that such half-hearted, yet over-heavy thread-safety be removed. Michaelp and I don't know who owns this (not dcone!). Try trudelle: Much of our non-static/global data needs to be partitioned by window, not reachable by other windows except through statics/globals. Therefore we're starting the hunt with statics and globals. Please have a look at the file(s) below to see if we can improve reentrantcy across the code base by making modifications to: widget/src/windows/nsObject.h: static CList s_liveChain; widget/src/windows/nsObject.h: static PRMonitor *s_liveChainMutex; widget/src/windows/nsObject.h: static int32 s_nObjects;

CVS Blame sez these lines came from Kipp, reassigning.

I don't own the widget library; somebody else does. And, I didn't write the mentioned code now matter what cvs-blame might say. It was written by "dario".

Nobody on xptoolkit has ever touched this file. We own the menu files in that directory, but not this. trying karnaze

RX tasks aren't going to make M3. close the reentrantcy tracking tasks if this specific area has been looked at and doesn't seem to be a problem. Otherwise each of these areas still need some looking at.

Rod and Kevin are the only ones I know of who have owned the widget code in the past. It makes more sense for XPFE to own it than layout. Peter, if you don't agree with this give me a call instead of us playing bugzilla tag.

After talking this over with several members of my team, I'm not sure why we should own it. Our menu code is moving elsewhere, and we don't do nsIWidgets.

reassigning to rods as p2 for m4

moving to m5

removed nsObject.h and cpp, the nsWindow class no longer derived from nsObject