3216 - RX: widgets - nsToolkit.h

Status: RESOLVED INVALID

(Core :: Widget: Win32, defect, P4)

Description

[chris hofmann]

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;

Comment 1

[Peter Trudelle]

Most of these are Kipp's, reassigning.

Comment 2

[kipp]

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".

Comment 3

[Peter Trudelle]

XPtoolkit team has never touched this file. We own the menu files in that
directory, but not this. trying karnaze

Comment 4

[chris hofmann]

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.

Comment 5

[karnaze (gone)]

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.

Comment 6

[Peter Trudelle]

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.

Comment 7

[Peter Trudelle]

reassigning to rods as p2 for m4

Comment 8

[Peter Trudelle]

moving to m5

Comment 9

[rods (gone)]

Moving to M6

Comment 10

[rods (gone)]

Changing to M8

Comment 11

[rods (gone)]

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".

Comment 12

[brendan-obsolete]

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

Comment 13

[Blake Ross]

reopening and marking Future...

Comment 14

[rods (gone)]

I am leaving this future for now.

Comment 15

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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).