On Jan 5, 2014, at 4:37 PM, Jim O'Connor <[email protected]> wrote: > > When my read stream finishes I schedule a timer to clean up on the runloop to > serialize access to shared resources. > However, I had a hang late last night because a mutex grabbed in the read > stream callback handler was held and was also being grabbed when the timer it > scheduled to clean up fired INSIDE the callback. > It was late and I didn't save the odd message in the Xcode stack crawl about > the timer being called OUTSIDE of the runloop. And now I can't get it to > repeat. > > I was under the impression that timers only fired when the RunLoop was > actually the top of the execution stack, or was called explicitly by me. Is > this not right?
Well, barring a memory smasher, CFReadStream isn’t going to directly invoke your timer callback function. But your use of “top of the execution stack” seems a little off to me. It’s possible to manually run a runloop from a deeper stack frame; this is often done by APIs which present a callback interface but need to use asynchrony internally. The run loop doesn’t care that it’s being run from code that itself is being indirectly called as a result of a turn of the same run loop, so it will fire its timers just like normal. --Kyle Sluder _______________________________________________ Cocoa-dev mailing list ([email protected]) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
