Clarify thread handling in NS_StackWalk() on Windows

RESOLVED FIXED in mozilla38

Status

()

Core
XPCOM
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: njn, Assigned: njn)

Tracking

unspecified
mozilla38
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

3 years ago
- 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.
(Assignee)

Comment 1

3 years ago
Created attachment 8551581 [details] [diff] [review]
Clarify thread handling in NS_StackWalk() on Windows

This patch fixes these problems.
Attachment #8551581 - Flags: review?(ehsan)

Updated

3 years ago
Attachment #8551581 - Flags: review?(ehsan) → review+
https://hg.mozilla.org/mozilla-central/rev/9ecca6f1d8b6
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla38
You need to log in before you can comment on or make changes to this bug.