Assign whatever identifier you want using dispatch_queue_set_specific(). You can then check your identifier using dispatch_get_specific(). Remember that dispatch_get_specific() is nice because it’ll start at the current queue, and then walk up the target queues if the key isn’t set on the current one. This usually doesn’t matter, but can be useful in some cases.
GCD does not perform preemptive cancelations. So, to stop a work item that has already started, you have to test for cancelations yourself. In Swift, cancel the DispatchWorkItem. In Objective-C, call dispatch_block_cancel on the block you created with dispatch_block_create. You can then test to see if was canceled or not with isCancelled in Swift (known … Read more
Updated answer: In current OS X and iOS, Dispatch objects are now treated as Obj-C objects by ARC. They will be memory-managed the same way that Obj-C objects will, and you should use strong for your property. This is controlled by the OS_OBJECT_USE_OBJC macro, defined in <os/object.h>. It’s set to 1 by default when your … Read more
Here’s a good example for you to try. Feel free to come back if you have any questions: self.mainThreadContext… // This is a reference to your main thread context NSPersistentStoreCoordinator *mainThreadContextStoreCoordinator = [self.mainThreadContext persistentStoreCoordinator]; dispatch_queue_t request_queue = dispatch_queue_create(“com.yourapp.DescriptionOfMethod”, NULL); dispatch_async(request_queue, ^{ // Create a new managed object context // Set its persistent store coordinator NSManagedObjectContext … Read more
You should condition spinning off this action on the non-nullity, not test for it after you’ve already initiated it: if let hostView = self.hostViewController?.view { DispatchQueue.main.async { hostView.addSubview(self.commandField) } } else { // handle nil hostView } You should never unwrap an optional outside of an if let, or testing it first. Doing this should … Read more
As the documentation describes, a global queue is good for concurrent tasks (i.e. you’re going to dispatch various tasks asynchronously and you’re perfectly happy if they run concurrently) and if you don’t want to encounter the theoretical overhead of creating and destroying your own queue. The creating of your own queue is very useful if … Read more
You should call all code from showAlertMessage on main queue: class func showAlertMessage(message:String, viewController: UIViewController) { DispatchQueue.main.async { let alertMessage = UIAlertController(title: “”, message: message, preferredStyle: .alert) let cancelAction = UIAlertAction(title: “Ok”, style: .cancel) alertMessage.addAction(cancelAction) viewController.present(alertMessage, animated: true, completion: nil) } }
dispatch_sync runs a block on a given queue and waits for it to complete. In this case, the queue is the main dispatch queue. The main queue runs all its operations on the main thread, in FIFO (first-in-first-out) order. That means that whenever you call dispatch_sync, your new block will be put at the end … Read more
From your stack trace, EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0) occurred because dispatch_group_t was released while it was still locking (waiting for dispatch_group_leave). According to what you found, this was what happened : dispatch_group_t group was created. group‘s retain count = 1. -[self webservice:onCompletion:] captured the group. group‘s retain count = 2. dispatch_async(…., ^{ dispatch_group_wait(group, …) … }); … Read more
The dispatch_get_global_queue (DispatchQueue.global() in Swift) gets you a background queue upon which you can dispatch background tasks that are run asynchronously (i.e. won’t block your user interface). And if you end up submitting multiple blocks to the global queues, these jobs can operate concurrently. If you have multiple blocks of code that you want to … Read more