send(_ action: Action) uses boolean as lock

[fabstu]

I looked at

swift-composable-architecture/Sources/ComposableArchitecture/Store.swift

Line 244 in 3cad5ac

if !self.isSending {

which features the following code.

  func send(_ action: Action) {
    if !self.isSending {
      self.synchronousActionsToSend.append(action)
    } else {
      self.bufferedActions.append(action)
      return
    }

Further down self.isSending is being set to true before entering the reducer and set to false after exiting the reducer. This seems to be a race condition waiting to happen. Did I miss something or is this not an issue? I imagine this does not matter in case send only comes from DispatchQueue.main or the same thread anyway, is that why its only a boolean? I've no idea wether functions are preemtible inflight or not though.

[AlexisQapa]

This is stated in https://github.com/pointfreeco/swift-composable-architecture#faq

[fabstu]

I try to understand how to avoid thread-safety issues. I hope I'm not bothering you, thanks for answering. I find this library awesome btw!

After reading the faq as far as I understand why send isn't thread-safe is because

• using a lock to limit access to the arrays/running one reducer at a time is too slow
• using a single queue would reduce speed in either case and UIScheduler is clunky and cost speed if we run on the non-main thread

Correct?

[... running reducers] cannot be done from multiple threads.

But further down is says:

If your effects are not responsible for their own scheduling, then in tests all of the effects would run synchronously and immediately.

Now im confused.

1. Is running reducers on different threads now wanted due to the reason above or not?
2. If its not wanted, what guards against this? Only running send from main or if from elsewhere than the usual thread then make sure to call receive(on:) manually yourself?

[AlexisQapa]

That's basically it. TCA requires to be run on a single thread.

TCA doesn't force you to use the main thread but Swiftui and UIkit are using the main thread so any actions from those is sent on the main thread. Now effects can be run on whatever scheduler you like but if you do so use receive(on:) to hop back to the main thread before dispatching the result to the store.

[fabstu]

Makes sense, thank you. This didn't come out directly from the faq, I found your explanation a better TLDR for what to do :-)

[mbrandonw]

Thanks for the discussion, I'll clarify the README sometime soon!