Closed Bug 1123533 Opened 5 years ago Closed 5 years ago

Clarify thread handling in NS_StackWalk() on Windows

Categories

(Core :: XPCOM, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla38

People

(Reporter: njn, Assigned: njn)

Details

Attachments

(1 file)

- The way NS_StackWalk() sets up |targetThread| and |data.walkCallingThread| is
  hard to read.

- The name |shouldBeThreadSafe| is unclear -- for a long time I thought it
  meant "we are thread-safe, so we can print" and I thought it was named
  incorrectly. But now I see it actually means the opposite, i.e. "we need to
  be thread-safe, so we can't print". So |needToBeThreadSafe| would be
  clearer...

- ...but |shouldBeThreadSafe| shouldn't be used anyway, because
  |data.walkCallingThread| is better -- it correctly handles the case where
  |aThread| is the current thread -- and it's what WalkStackMain64() uses.
This patch fixes these problems.
Attachment #8551581 - Flags: review?(ehsan)
Attachment #8551581 - Flags: review?(ehsan) → review+
https://hg.mozilla.org/mozilla-central/rev/9ecca6f1d8b6
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla38
You need to log in before you can comment on or make changes to this bug.