Why do we need isSending in Store implementation?

[evilhonda3030]

Hi folks. First of all I want to thank all community around TCA and especially major TCA contributors for this wonderful spreading of all this info regarding to functional programming, redux and in general a new way to consider architecture of presentation layer.

Even I don't use TCA directly I was inspired by its approach so I am utilising likely a similar ad hoc solution.

First time, I was getting to know the codebase of TCA I was concerned by existence of isSending flag in send method of store. The reason it was put there is so unclear for me because TCA was invented as a single thread solution (queue) so all code executing on a single thread must follow each other sequentially. Basically I see here "code" as a single task or a single invocation of send method.

Taking into account this serial nature of TCA I can't understand how yet another callee of send method can invoke it before a previous invocation of send is finished

Why am I asking?

1. I am just interesting how concurrency works here exactly because I am freaking about it actually)
2. Today I got EXC_BAD_ACCESS using a store without isSending flag. My solution was just several textfield sending actions to store and repository which state was mutated synchronously from send method. All actions were being sent on Main Thread, mutation took place on Main too but after I did this trick with isSending I definitely could see that it was possible to invoke send another time before the last invocation was finished

So basically to pose isSending was enough to solve exception but I am still confused because I can't understand why the overall situation is possible.

Could you guys elaborate on it? Thanks in advance!

P.S. I searched for another isSending question but it didn't answer mine unfortunately(

[mbrandonw]

Hi @evilhonda3030, the isSending boolean doesn't have anything to do with threading in the store. Instead, it has to do with "re-entrant" actions, which can happen even in a single threaded Store.

A re-entrant action is when an action is sent while an action is currently being processed. We personally think people should try their hardest to avoid re-entrant actions, but we can't force that on people so we try our hardest to support it in the most reasonable way possible.

To see a bunch of ways re-entrant actions can happen, just try commenting out this line in Store.swift and then run the test suite:

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

Line 327 in c9259b5

guard !self.isSending else { return nil }

You'll get a few failures, but more than that you will get test crashes.

For example, the testActionQueuing test crashes. This test shows what happens when a reducer causes an effect to emit directly in the switch:

swift-composable-architecture/Tests/ComposableArchitectureTests/StoreTests.swift

Lines 325 to 330 in c9259b5

	case .incrementTapped:
	subject.send()
	return .none
	case .`init`:
	return subject.map { .doIncrement }.eraseToEffect()

This clearly shows how a re-entrant action can happen. While processing incrementTapped, the effect returned from init emits, causing a new action doIncrement to be sent.

Now, we don't think it's a good idea to ever do this, but some people have found themselves in this situation, and so we should support it.

Another example is in this test:

swift-composable-architecture/Tests/ComposableArchitectureTests/CompatibilityTests.swift

Lines 101 to 107 in c9259b5

	viewStore.publisher
	.sink { value in
	if value == 1 {
	viewStore.send(0)
	}
	}
	.store(in: &self.cancellables)

It sends an action from within the observation of a state change. This too causes an action to be sent while in the middle of processing an action.

And all of this happens even though everything is single threaded and takes place on the main thread. So, we need to track isSending and bufferedActions so that all re-entrant actions can be gathered and then processed later. And there are even more subtleties to the problem beyond what I have described above. 🙂

[evilhonda3030]

Yeah, make sense. Even if it doesn't answer my underlying question it gives an insight on what this flag is for.

Therefore, it must easier to reason about the problem I faced.

Maybe one day I realize why I got that exception and post my thoughts here if the community doesn't mind.

Thank you for your response. I deeply appreciate it!