Re: How can main thread be blocked in mach_msg_trap?
Re: How can main thread be blocked in mach_msg_trap?
- Subject: Re: How can main thread be blocked in mach_msg_trap?
- From: Michael Ash <email@hidden>
- Date: Sun, 22 Mar 2009 07:21:23 -0400
On Sat, Mar 21, 2009 at 11:54 PM, Jerry Krinock <email@hidden> wrote:
>
> NSLogs tell me that, when one of my secondary threads executes a
> performSelectorOnMainThread::: at a certain point, the requested method
> never begins. So I conclude that the main thread ^is^ blocked.
>
> But if I "Pause" the debugger at this point and examine the call stack for
> "Thread-1", I see:
>
> #0 0x9540b1c6 in mach_msg_trap
> #1 0x954129bc in mach_msg
> #2 0x9495f0ae in CFRunLoopRunSpecific
> #3 0x9495fcd8 in CFRunLoopRunInMode
> #4 0x929ced75 in -[NSRunLoop(NSRunLoop) runMode:beforeDate:]
> #5 0x929dae94 in -[NSRunLoop(NSRunLoop) run]
> #6 0x00002a3f in main at Worker-Main.m:112
>
> I always thought that mach_msg_trap means that a thread is sitting at the
> top of a run loop waiting for an input source, such as
> performSelectorOnMainThread:::, to wake it. Therefore it is ^not^ blocked.
>
> My understanding thus ends in a paradox. How can this be explained?
>
> (Notice that this is a background agent in which I have explicitly invoked
> -[NSRunLoop run])
Several possibilities:
1) You've never actually made the call to
performSelectorOnMainThread:..., you just think you have.
2) The call worked, and the target executed, and finished before you
paused in the debugger.
3) You're sending it to nil.
4) You're running the runloop in a mode that the perform... call isn't
looking for.
Mike
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden