[Accepted] SDL 0187 - Restructure iOS Threading and Queueing

[theresalech]

Hello SDL community,

The review of "SDL 0187 - Restructure iOS Threading and Queueing" begins now and runs through July 17, 2018. The proposal is available here:

https://github.com/smartdevicelink/sdl_evolution/blob/master/proposals/0187-restructure-ios-threading.md

Reviews are an important part of the SDL evolution process. All reviews should be sent to the associated Github issue at:

#543

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of SDL. When writing your review, here are some questions you might want to answer in your review:

• Is the problem being addressed significant enough to warrant a change to SDL?
• Does this proposal fit well with the feel and direction of SDL?
• If you have used competitors with a similar feature, how do you feel that this proposal compares to those?
• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
  Please state explicitly whether you believe that the proposal should be accepted into SDL.

More information about the SDL evolution process is available at

https://github.com/smartdevicelink/sdl_evolution/blob/master/process.md

Thank you,
Theresa Lech

Program Manager - Livio
theresa@livio.io

[NickFromAmazon]

This is great, should be immensely helpful for performance and general stability.

Just a couple of quick questions:

• Concurrent Queue "com.sdl.processing.concurrent" - general SDL processes that await callbacks, such as sending RPCs, will occur in this queue

Could you elaborate on use cases for this one? It's probably just my lack of familiarity with the RPC logic, but I'm curious when it would be necessary to block waiting for responses (as opposed to handling responses asynchronously as separate tasks.)

We should begin preferring NSOperationQueue above large stretches of dispatch_async code

What's the rational for this? I don't have an issue with this, just curious as using NSOperation subclasses does introduce some complexity.

I'd recommend extensive testing with the Thread Sanitizer Diagnostic option enabled as a criteria for completion, which would provide a reasonable level of confidence in the solution. As of 6.0 this generates quite a bit of noise, and is likely a barrier to adoption as it inhibits client's ability to debug threading issues in their own code.

[joeljfischer]

Concurrent Dispatch Queue & NSOperationQueue

The main (perhaps only) reason for the use of a concurrent dispatch queue is the use of NSOperationQueue in the code. These (operation) queues are often serial, though one is currently concurrent (for sending multiple RPCs). For example, the choice set manager makes extensive use of an NSOperationQueue to keep the various possible operations (preloading, deleting, presenting of various kinds) modular, testable, and serialized. The issue is that one operation must finish entirely before the next operation can take place.

So, first, if the dispatch queue was serial, an operation in one NSOperationQueue would block those of another. Plus, an operation that sends an RPC and waits for a response before finishing the operation will block all other operations until that RPC response returns.

Testing with the Thread Sanitizer to ensure that we are not causing an explosion of threads is a good idea.

I hope that was clear, dispatch queues and operation queues can both be called queues and I tried to make sure it was clear when I was talking about one or the other.

[theresalech]

The Steering Committee fully agreed to accept this proposal. It was also confirmed during discussion that this proposal does not make any changes regarding minimum version.

[theresalech]

Issue Entered: [SDL 0187] Restructure iOS Threading and Queueing