should be per-document, not global (static). More for 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/nsToolkit.h: static HINSTANCE mDllInstance; widget/src/windows/nsToolkit.h: static MouseTrailer* theMouseTrailer; widget/src/windows/nsToolkit.h: static nsWindow* mHoldMouse; widget/src/windows/nsToolkit.h: static PRBool gIgnoreNextCycle; widget/src/windows/nsTooltipWidget.h: static BOOL sTooltipWidgetIsRegistered; widget/src/windows/nsWindow.h: static nsWindow* gCurrentWindow; widget/src/windows/nsWindow.h: static BOOL sIsRegistered;

Most of these are Kipp's, 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".

XPtoolkit team has never 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

Moving to M6

Changing to M8

I am not enough of a Window's DLL guru to answer this question. I need someone's help! I am accepting it as a "remind".

I don't think you need to be a DLL guru here (maybe I'm wrong). Also, it could well be that the code in question is already reentrant, in spite of having static data; or it may not need to be reentrant, because it can't be active on the stack when re-activated from a modal dialog (to draw a widget or whatever). The thing to look out for is data dependencies, and also anti-dependencies, that span a call out of the module to a function that could nest an event loop (any function that might run JS could nest an event loop). /be

reopening and marking Future...

I am leaving this future for now.

I don't think this list of a few static variables in widget/src/windows/ is useful at this point for helping make Gecko multithreaded (if we ever decide to go that route). If we ever want to do that, we'd need to start this type of analysis (and more) over again. So marking as invalid (not because it's strictly invalid, but because I don't think we should have a bug report on such a small part of the problem).