Understanding System Trace's Main Thread 'Blocked'

Question

Created Aug ’18

Replies 2

Boosts 0

Views 7.1k

Participants 3

We've lots and lots going on at startup, but in particular we've some items which can for a very short period of time block the main thread, causing a UITableView stutter on scroll.

https://imgur.com/a/RWDvFJz

Using the 'System Trace' tool, we can clearly see on the Main Thread some 'blocked' states. However, I'm finding it difficult to pinpoint down in code where this happens.

If I find the 'mach_msg_trap' associated with a particular blocking item, the Stack on the right has a basic stack (see: https://imgur.com/a/tNnXQvh), but double clicking on main brings a function which couldn't possibly be the cause of a blocker (as it's a ViewModel which in this case doesn't get initialized in this flow).

Is it possible to fixture out, even what thread is blocking, so I can find that thread at the time, and look at it's call stack?

Boost

Answer 1

OP

Apple

Aug ’18

The backtrace says the main thread is waiting in the run loop. In other words, it's waiting for user input, a timer, a socket, or some other run loop source to fire. There is currently no way to know which run loops sources are active, like a list of timers or sockets.

0

Answer 2

jiangwang OP

Sep ’22

Waiting for user input? So, it's normal then? I found out about this same issue. Couldn't understand what it means by saying the main thread is "blocked", because my application runs fine. And "blocked" will show when I am actually not scrolling or tapping anything in my application. https://stackoverflow.com/questions/73616263/main-thread-showing-blocked-from-instrument-by-mach-msg-trap

0