Child Item

Objective-C V2 SDK thread safety

I am just in the middle of implementing a syncing solution using the Obj-C V2 SDK.

I have a couple of concurrent threads. One for checking for (and downloading) any remote changes, and another for uploading local changes.

This could potentially involve some concurrent usage of the V2 SDK. For example simultaneous listFolder calls, or simultanoues download and upload calls. So I was wondering whether this was an issue from a thread safety perspective. I know it uses NSUrlSessions behnid the scenes, but not sure how safe such concurrent operations would be....

Find more posts tagged with

API

Abuse

Comments

Stephen C.14

Thanks for reaching out. Currently, the SDK is not thread safe. There is an implicit assumption that all requesting is done serially from the same thread. Response code is executed serially on whichever thread (NSOperationQueue) you supply, for the given request.

As you pointed out, the networking layer is implemented using NSURLSession, so it's fine to spawn a bunch of requests at once (provided there aren't so many that you run into the timeout limit), and those requests will be processed concurrently.

I wanted to get a sense from you about how important thread-safety is for your use case, at which point, we can consider potentially implementing a thread-safe SDK. Given that the real bottleneck (managing the network requests) is all handled concurrently by the NSURLSession library, is it a significant burden for your app to simply dispatch API requests to a common thread, and have response handler code executed serially on whichever response thread you supply?

Mark R.5

Hi. Thanks for the response.

I will create a new serial queue and make sure all API calls are dispatched to this queue for the time being. It is not a massive issue since it is relatively easy to workaround using GCD, but it does start to get a bit messy. In my case I want to maintain two separate concurrent threads, one for downloads and one for uploads. Now I also have to offload to a serial queue for the API calls, while keeping the rest of the sync logic on the concurrent queue. This means that I need to add code to wait for the API calls to return. I can do this using a dispatch_semaphore_t and waiting on the callback to complete, but this does start to become difficult to manage the more calls you have. Personally I would rather not have to worry about this and be able to make API calls from any thread.

On a related note, I am also implementing this syncing solution using the dot-net sdk. This is different in that the API methods are generally async and you await them, so evertthing is effectively handled inline on the same thread. Does this framework also have potential thread safety issues, since I have a similar design with two concurrent threads making API calls...

Stephen C.14

Thanks for letting me know. I looked into making the Obj-C SDK threadsafe, and I actually don't think it will require much work on my end, so I'll go ahead and do that, and put out a new version later today. If you wouldn't mind, try it out, and see if you run into any threading issues. I'm pretty sure I accounted for everything, but all the same, it would be helpful testing it with your use case.

.NET SDK is threadsafe, so no worries there.

Stephen C.14

Hey Mark, check out the latest version of the SDK, v.3.0.8. It is now thread-safe. You should be able to make requests from any thread.

Let me know if you run into any issues!

Mark R.5

Fantastic! Just to confirm, I manually added the subproject, so to update to 3.0.8 is it at simple as doing:

carthage update --platform iOS

or is there anything else required?

Greg-DB

That depends on what you have specified in your Cartfile. If you have a specific version number or range set, you may need to update that before you call update.

But yes, once you have your Cartfile configured as desired, just run "carthage update --platform iOS" to update. You can then check the console output or Cartfile.resolved file to see exactly what version was installed.

Mark R.5

Thanks, I have

github "https://github.com/dropbox/dropbox-sdk-obj-c" ~> 3.0.3

in my Cartfile. I only installed Carthage to use this framework so not too familiar with it yet. The 'resolved' file seems to imply that 3.0.8 is now installed, so I think it is all good.

It would be good if the framework could output its version number upon initialisation. I have had problems in the past with accidentally using the wrong versions of libraries and it would be useful and reassuring to get confirmation of the version number at runtime.

I will monitor this version to see how it behaves, but no problems so far.