NSRunLoop runMode blocks on app start #36

Closed
ViktorasJucikas opened this Issue Oct 29, 2012 · 2 comments

Projects

None yet

2 participants

@ViktorasJucikas

Code snipped below from flushEvents/People in Mixpanel.m seems to be blocking the main thread.

Symptoms: whenever app comes to foreground there's a lag of ~5secs while you can't do anything because UI is blocked. Instruments are showing that below is running then, commenting flushEvents/People out removes this lag.

This is related to a fix to issue 35 (#35) - on app going to background new thread is started and code below tries to keep it alive. The only reason to have a new thread there seems to be this 5sec limit which could run over if you were to base64 encode lots of data (you can actually base64 encode quite a bit of data in 5secs) because NSURLConnection calls are non-blocking.

So maybe the solution is to change it so NSURLConnection is blocking if you think 5secs is not enough to encode data? Or maybe change below in a way so it doesn't block the main thread?

A side bug of the below is that if you're under a very slow connection and close the app and immediately reopen it it crashes - seems to be that this background thread is still kept alive while a new one kicks in for foreground processing but the self.eventsConnection is still alive and they both try to clear it which results in crash.

 if(![NSThread isMainThread]){
       DevLog(@"%@ keeping background events connection thread alive", self);
       while(self.eventsConnection) {
           [[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode beforeDate:[NSDate distantFuture]];
       }
       DevLog(@"%@ letting go of background events connection thread", self);
   }
@neilrahilly

Thanks again, Viktoras.

@ViktorasJucikas

Cheers Neil.

@samgreen samgreen added a commit that referenced this issue Apr 18, 2016
@samgreen samgreen Ae tweaks (#36)
* Correct the capitalization of Xcode in README

* Fix typo in HelloMixpanel

* Solved Issue #455 in regards to: In-app notifications truncating instead of moving text to second line. Added auto layout to the Notification Storyboard to work well with Portrait and Landscape mode.

* Resolves watchOS integration when using more than one instance of the Mixpanel SDK.

* Cleaning up modulemap files, Add MPTweak to Carthage project

Require only App-Extension-Safe API for watchOS

* Archive on every flush

* Using Carthage framework as a dependency instead of including source code in the test app.

* Cleaning up modulemap files, Add MPTweak to Carthage project

Require only App-Extension-Safe API for watchOS

* Archive on every flush

* Integrate carthage project with sample app.

* Simplify watchOS implementation

* Crash fix for mp_important color

* Fix mp_important color to be more safe, and leverage CoreGraphics instead of hard coded magic numbers.

* Bump version and update version in podspec

* Revert "Merge sample update"

This reverts commit d619c43, reversing
changes made to da158a5.

* Revert variant stop change in decide response.

* Update docs.

* Tweaks to get sample app running again.

* Only track text field notifications when editing ends.

* Clean up internal tracking

* Sample clean up

* Change sample to use framework instead of source files.

* Reorganized Xcode groups.

* Update libicucore linking

* Blacklisted internal Apple view controllers.

* Fixed duplicate notification tracking, and removed one swizzle, since it seems like Apple is delegating to the last function

* Remove NSNotification swizzle

* Resolve issue with clang modules in sample app.

* Enable modules on the app but not the framework
d7cf73d
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment