Threading

Siesta maintains a simple thread model.

All operations involving shared state:

• happen on the main thread, and
• return very quickly (nanoseconds) for typical use.

All operations expected to be time-intensive:

• use only structs (i.e. non-shared data) for their input and output, and
• run on GCD background queues.

Main Queue Operations

The vast majority of Siesta’s API surface falls into that “quick return, main thread only” category. This means that you must call all methods of all the following types from the main thread:

• Service
• Resource
• Request

In development builds, internal Siesta assertions will flag most violations of this rule.

Because they are likely to update the UI, Siesta calls the following user-provided callbacks on the main thread:

• ResourceObserver methods and
• Request hooks.

It is your responsibility to ensure that your callbacks do not block the main thread for excessive amounts of time.

Background Queue Operations

Because they may involve parsing and transformation of large amounts of data, Siesta performs these two tasks on GCD background queues:

• response parsing and
• entity caching.

You thus must ensure that the following are threadsafe:

• closures you pass to configureTransformer and ResponseContentTransformer,
• implementations of ResponseTransformer, and
• implementations of EntityCache.

All of these pass only structs as input and output, so you will typically not need to do any synchronization dances with them. However, you will need to be careful about using shared resources, such as a cache’s data store. Also take care if you work with entities whose content is a mutable object and not a struct.

Networking and Threading

This section is only of concern if you are writing a custom networking provider.

Most networking libraries use threads internally (including URLSession, Siesta’s default). Siesta therefore delegates threading responsibility to the networking provider. If you write a custom NetworkingProvider implementation, you thus must exercise a little care about threading.

Siesta will always call your startRequest() on the main thread, but it is safe to call the completion callback from a background thread without any synchronization.

It is your responsibility to ensure that any code that queries or alters the state of a request in progress does so in a threadsafe manner. This includes the members of RequestNetworking. (Most networking libraries already provide the necessary thread safety, and you won’t need to take any thread safety measures yourself. Just make sure that this is indeed the case!)

Next: Logging