Start using a "jobs queue" (ie an OperationQueue) for processing tasks about locokit HOT 4 CLOSED

So I've just discovered that iOS 12 is killing Arc on newer model phones after as few as 4 seconds of processing in the background.

https://twitter.com/sobri/status/1059130940616634368?s=21

Which is ... well, I have very impolite words to say about that. Very impolite words indeed. That is Very Uncool of Apple. It is not cricket. If I had an Apple engineer within awkward confrontation reach right now, we would be having an awkward confrontation.

Anyway, that means that for background processing tasks to survive they are going to have to be micromanaged down to the second, taking into account how many cores (threads) they are being spread over during each second of the task. The energy consumption micromanagement task complexity just went through the roof.

All of that means that this task just went from being "fun thing to work on later" to being top priority, and also requiring considerably more complexity than I'd planned. So I'll be working on this tomorrow. Whilst saying angry things that are best not typed.

Uncool Apple. Uncool.

from locokit.

Hunting through the energy reports further, it really does look like this is an iOS 12 bug. It is punishing multithreaded code on newer model devices that have more cores. Older phones are surviving fine because they've got less cores.

iOS 12 shouldn't be punishing apps for running more efficiently on newer devices. There's no sense to that. So yeah, I smell an iOS bug.

So perhaps I should be reporting this to Apple. Although I loathe going down the Radar sarlacc unless absolutely necessary.

I'm also not able to clearly see the individual threads in Xcode's energy stack traces. It looks like it's showing the trace of a single thread, but ... it can't be. It's not possible to get 1200% CPU consumption from a single thread (or if it is, I will be very surprised), so there's definitely more to the story here that I'm going to have to piece together tomorrow. Sigh.

from locokit.

Goals

• Optimise for speed and parallelism in foreground
• All background tasks must be done at .background priority
• All background tasks must be done strictly in serial (parallelism will trigger the iOS 12 bug)
• Ensure that current serial queues still have their serial nature enforced

Todos

• Serial processing queue
• Parallel processing queue
• Parallel queue reduced to serial while in background
• Parallel queue suspended in background while serial queue not empty
• Pending operations on both queues reprioritised to .background on entering background
• Compulsory 60 second pauses between serial operations in background
• Logging of operation durations (to raise awareness of potential >60 second tasks)
• Don't pause the serial queue while in recording mode
• Deduplicate the queue pause code (there's still a race condition)
• 60 second gap is getting shortened due to above race condition
• Add serial queue jobs at higher priority in foreground
• Send a notification when a job runs for longer than 60 seconds
• Spare a thought for queuePriority, because it might have some immediate use
• Collate queue statistics, for more nuanced job management, and debug logging
• Investigate background resource consumption monitoring possibilities

from locokit.

I've merged this into develop now. It's proven stable in Arc 2.2.14 and 2.2.15.

There's a few more things I want to do with it, but they aren't urgent.

from locokit.