objective c - How to determine what's blocking the main thread -
so restructured central part in cocoa application (i had to!) , running issues since then.
quick outline: application controls playback of quicktime movies in sync external timecode.
thus, external timecode arrives on coremidi callback thread , gets posted application 25 times per sec. sync checked , adjusted if needs be. checking , adjusting done on main thread.
even if put processing on background thread ton of work i'm using lot of gcd blocks , need rewrite lot of functions can called nsthread. make sure first if solve problem.
the problem
my core midi callback called in time, gcd block dispatched main queue blocked 500 ms. understandable adjusting sync not quite work if happens. couldn't find reason it, i'm guessing i'm doing blocks main thread.
i'm familiar instruments, couldn't find right mode see keeps messages being processed in time.
i appreciate if help. don't know can it. in advance!
you may blocking main thread or might flooding events.
i suggest 3 things:
grab timestamp when timecode arrives in coremidi callback thread (see
mach_absolute_time(). grab current time when main thread work being done. can adjust accordingly based on how time has elapsed between posting main thread , being processed.create kind of coalescing mechanism such when main thread blocked, interim timecode events (that out of date) tossed. can simple global nsuinteger incremented every time event received. block dispatched main queue capture current value on creation, check when processed. if differs more n (n determine), toss event because more in flight.
consider not sending event main thread every timecode notification. 25 adjustments per second a lot of work. if processing 5 per second yields "good enough" perceptual experience, awful lot of work saved.
in general, instrumenting main event loop bit tricky. cpu profiler in instruments can quite helpful. may come surprise, can allocations instrument. in particular, can use allocations instrument measure memory throughput. if there tons of transient (short lived) allocations, it'll chew ton of cpu time doing allocations/deallocations.
Comments
Post a Comment