Queuing actions with unique parallelism limiting semantics
How would I go about ensuring concurrency semantics with actions that are more complex than what workpools and workflows currently provide? For example, sequentially executing some actions enqueued by a specific user, because these actions could change state relating to the user and put it in a state that other actions are not allowed to run in.
I've implemented a queue on top of workflows for this purpose, but considering how complex the workpool implementation is, I can't imagine it's actually very sound. I haven't even touched back pressure yet.
Given my requirements, and the highly specific implementation of these concurrency related components, do I have no choice but to entirely DIY it?
Is this a code smell?
I've implemented a queue on top of workflows for this purpose, but considering how complex the workpool implementation is, I can't imagine it's actually very sound. I haven't even touched back pressure yet.
Given my requirements, and the highly specific implementation of these concurrency related components, do I have no choice but to entirely DIY it?
Is this a code smell?
