Suppose I have the following situation. I have a thread, and this thread is holding a lock. While it's doing so, I call pthread_create, so now I have two threads. Suppose the second thread gets to unlock the lock. What happens when the first thread hits the unlock?
A thread should only unlock a lock that it has locked itself, and thus your second thread should not attempt to unlock a mutex that has been locked by the first thread.
Trying to unlock a mutex that has been locked by another thread is undefined behavior, unless the mutex type is PTHREAD_MUTEX_ERRORCHECK, in which case an error is returned.
More info here: http://linux.die.net/man/3/pthread_mutex_lock
Relevant section:
If the mutex type is PTHREAD_MUTEX_NORMAL, deadlock detection shall
not be provided. Attempting to relock the mutex causes deadlock. If a
thread attempts to unlock a mutex that it has not locked or a mutex
which is unlocked, undefined behavior results.
If the mutex type is PTHREAD_MUTEX_ERRORCHECK, then error checking
shall be provided. If a thread attempts to relock a mutex that it has
already locked, an error shall be returned. If a thread attempts to
unlock a mutex that it has not locked or a mutex which is unlocked, an
error shall be returned.
Related
When we receive some crash logs from Apple(TestFlight) which contain next some error:
Modifications to the layout engine must not be performed from a background thread after it has been accessed from the main thread.
for example or etc.
And we can't reproduce it under debug. It just happens. And we have only crash logs.
How to detect initial caller background thread by crash log only?
If it’s possible.
I'd like to get UIApplication.shared.applicationState from a background thread. If I try to get the application state from a background thread, I get errors when accessing it since it's not the main thread (since it's a UIKit API).
The reason I'm doing this is so I can log events that also includes information such as the current application state. Logging events for me is happening in the background so it does not lock up the main thread.
Is there an alternative for getting the application state within a background thread?
Setup notifications for changes to the state on the main thread and assign them atomically to a variable. That variable can now be accessed atomically as well from your background thread.
In my ios app, I start listening user's location updates in the background for a while (up to 15 mins) when I receive background fetch execution. However, after I stop updates, the app crashes with the 0x8badf00d error.
I've enabled background location and background fetch permissions, and I also have enabled background location updates on CLLocationManager.
Any idea on why this error happens?
The problem isn’t that it isn’t running in the background, but rather whatever was running was blocking the main thread.
The 0x8badf00d (“ate bad food”; lol) indicates that the watchdog process (that monitors for dead/blocked processes) killed your app, generally because you did something to block the main thread. If you avoid blocking the main thread, this error should go away. See Technical Note 2151: Understanding and Analyzing Application Crash Reports and search for 0x8badf00d.
As it says:
The exception code 0x8badf00d indicates that an application has been terminated by iOS because a watchdog timeout occurred. The application took too long to launch, terminate, or respond to system events. One common cause of this is doing synchronous networking on the main thread. Whatever operation is on Thread 0 needs to be moved to a background thread, or processed differently, so that it does not block the main thread.
They’re focusing on synchronous network requests, but it can be anything that blocked the main thread for too long, whether a slow synchronous process or a deadlock or whatever. You should look at the stack trace for thread 0 and see if you can identify what blocked the main thread. There’s not enough here for us to diagnose it, though.
Common culprits include synchronous network calls, synchronous GCD calls, inappropriate use of semaphores, locks, or dispatch group “wait” calls, deadlocks, etc.
I have an instance of AVAudioRecorder and I have noticed that when the user closes the app too fast with a larger recording the file does not get saved properly.
This even happens when I call [recorderObject stop] in the main thread and the file gets saved locally.
I have also tried moving the file after the recording has stopped (in the (void)audioRecorderDidFinishRecording:successfully: method). But I have noticed that when I do the move with NSFileManager in a background thread with high priority, it too doesn't always finish.
Is there a way for me to insure that the files get saved, even if the user exits the app shortly after finishing a longer recording?
Thanks
Review Apple's documentation for executing tasks in the background.
Apps moving to the background are expected to put themselves into a
quiescent state as quickly as possible so that they can be suspended
by the system. If your app is in the middle of a task and needs a
little extra time to complete that task, it can call the
beginBackgroundTaskWithName:expirationHandler: or
beginBackgroundTaskWithExpirationHandler: method of the UIApplication
object to request some additional execution time. Calling either of
these methods delays the suspension of your app temporarily, giving it
a little extra time to finish its work. Upon completion of that work,
your app must call the endBackgroundTask: method to let the system
know that it is finished and can be suspended.
In my iPhone App, login function is accessing internet in the main thread.
Is it ok to access internet in the main thread?
Some other processes are also accessing internet in main thread in different screen.
Will it be rejected in review process?
Please guide me.
Thanks.
--Ruhul
As a rule, network access should never be done on the main thread since it blocks the UI and make the app appear unresponsive, because all the UI operations are carried out on the main thread exclusively. There is no specific Apple guideline on not allowing apps which access the network on the main thread, but it may be rejected for the reason of having poor usability due to the UI interaction being blocked for the duration of the network call.