Hey @Ragnar and @shaunvdberg > , great convo here around threading and Flows in C#. As a Java guy, our API is a bit different.
So, in C# (and C) the callback that the Flow runs when it receives a message is on the API Context thread, and there’s only one of those, so blocking up that thread is bad for a number of reasons. And since you can acknowledge messages from anywhere, any thread, a typical setup for an app that might take a while to process messages would be:
onMessage (API thread) → take message, place in linked list or ring buffer or something, return
(Application-owned thread) →
block taking messages off linked list or ring buffer
do processing
ACK message from there
check if app is suppposed to exit?
Which I guess would lend itself well to building a multi-threaded parallel processor? You could have multiple application threads reading from that linked list or in-memory queue and processing in parallel. (IF ORDER DOESN’T MATTER).
Shaun: why/when would you want to force a redelivery of a message from the queue (by closing the Flow)? Like, if it couldn’t be processed/parsed, or if some downstream system you’re sending it to is unavailable? You could build some retry logic into your processing function?