What's the implication of a larger number -- 2494 ReceiveNextEventCommon
11 ReceiveNextEventCommon
It means that all 2505 of that thread’s backtraces that included
_BlockUntilNextEventMatchingListInModeWithFilter also included
ReceiveNextEventCommon, but not all of them were at the same site within
ReceiveNextEventCommon. Imagine an implementation of
ReceiveNextEventCommon that looks like this:
Code Block | on ReceiveNextEventCommon |
| while true |
| event = RunCurrentEventLoopInMode |
| DoSomethingWithEvent(event) |
| end while |
| end |
2494 of the backtraces included
RunCurrentEventLoopInMode and 11 included
DoSomethingWithEvent (note that I’m making up that symbol name because I don’t have access to the sample I took yesterday). This is pretty much what I’d expect. Most of the backtraces run through
RunCurrentEventLoopInMode because that blocks waiting for the next event. Some run through
DoSomethingWithEvent as the program processes the events that it received.
I'm imagining a listing that, instead of being hierarchical is more or
less flat, repeating over and over again. Is that what you mean?
Well, there’s two common modes:
The program might be running a complex framework, in which case there will be a complex forest of trees with none of the leaf nodes being particularly heavy.
The program might be stuck inside a computation loop, where there’s a single very heavy leaf node.
The key thing is that there’s obviously no blocking leaf node, like
mach_msg_trap.
When you say "blocked" and "not blocked" I'm in a JavaScript headspace
where synchronous block the next command and asynchronous step aside
and let the next steps run
JavaScript is a bit weird because it doesn’t have threads (some might argue that’s a good thing :-). So all long-running operations must necessarily be async (either with callbacks or async/await). If you did a long-running operation sync, you’d lock up the entire JavaScript engine for the duration O-:
Native code supports threads, which means that, for better or worse, sync operations are possible. For example, in BSD Sockets, if you do a
read on a socket, it won’t return until it gets some data or gets an error.
To support this efficiently the system must implement the notion of blocking. The code can’t spin in a loop waiting for network data to arrive because that burns through CPU and battery. Rather, the system blocks the thread and then unblocks it when something interesting happens.
Taking a step back, if you poste a copy of your sample I’d be happy to take a look. Use the text attachment feature (the paperclip icon) to avoid clogging up the timeline.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
