Calling into the reducer from a background thread directly

[quantamrhino]

I have an mic tap which returns audio data at a high rate, from a background (Audio thread) context.
In this audio thread context, apple says it's not allowed to sleep or block or allocate memory etc. How do I offload that work to a reducer?
I would like to invoke an action in a reducer, and then continue running analysis code in the background, on a different thread. (ideally without the main thread hop, then a .run to take it off the main thread again).
If I declare a global store, I can't send actions on it without the withViewStore.
So how are non-views to send an action to a store?
I'm completely at my wit's end trying to figure this out.
I do hope I don't have to scrap TCA because I do really love it and the test coverage and reasoning ability it provides.
Thank for any help/insights you can provide!

My reducer is simple, like this:

struct CallbackManager: ReducerProtocol {
   enum Action {
      callback(audio)
      update(result)
   }

   struct State {
        // some state that the callback reducer drives, that the UI shows
       var result: AudioResult
   }


  func reduce(...) {
        case .callback(audio):
              return .run { send in
                    // process the audio off the main thread, and send back an update effect to update the UI, 
                    // which will be on main thread due to reducer
                    await send(.update(result))
             }
       }
}

[mbrandonw]

Hi @quantamrhino, is it necessary to send actions into the system at a high frequency? In particular, does the reducer do real logic with each little audio update, or is it just accumulated into some final value?

In general, you should avoid sending actions at a high frequency in TCA. We have a dedicated section to this topic in our performance article. Instead of sending many actions from an effect you can often perform all the work needed in the effect, and send a single summary action at the end, or a few progress actions along the way.

Any work you perform inside Effect.run will be off the main thread, though it will be performed in the cooperative thread pool which is quite small. You should not do a lot of blocking work in there. In order to perform CPU intense work in an effect in a cooperative manner, you should sprinkle in some Task.yield()s so that other tasks get a chance to perform their work in the cooperative pool.

I'm not sure if any of the above helps, but if it doesn't then I think it would help to get more details about your exact situation and a bit more code.

And there is one thing in your message that may be a misunderstanding, so here is some clarification:

If I declare a global store, I can't send actions on it without the withViewStore.

This is not true. You can send actions using a plain ViewStore too, which is the thing that actually does the observing of stores, and is what WithViewStore uses under the hood. The term "view store" isn't meant to convey that it is a thing appropriate for views, but rather that it is a view into a store so that you can observe and access the state on the inside. You can always even do something like ViewStore(store).send(.action) if you just want to send an action with no fuss.

[quantamrhino]

Thanks for your prompt response.
The mic tap shows a level meter and some other analysis as animation, so that's why it's high frequency, as the level changes etc.
I could make a global object with the mic tap that is setup at app launch time and then have a global Store object, then just the UI updates can be sent to the store via ViewStore(store).send(.updateLevel), If I understood your meaning.