You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently callbacks are implemented in a way that they can be shared, i.e. reused by multiple different requests and/or workflows. This made a lot of sense in the first iteration of bevy_impulse when everything was one-shot and repeatedly creating and dropping systems doesn't make much sense.
Now that workflows are fully reusable, there may be legitimate use cases where someone wants to drop a callback system into a specific node of a workflow and not reuse the system anywhere else. In those cases, there is an unnecessary mutex locking being done each time the node is run.
We can avoid the mutex lock if we have two flavors of callbacks: unique and shared.
The text was updated successfully, but these errors were encountered:
Currently callbacks are implemented in a way that they can be shared, i.e. reused by multiple different requests and/or workflows. This made a lot of sense in the first iteration of
bevy_impulse
when everything was one-shot and repeatedly creating and dropping systems doesn't make much sense.Now that workflows are fully reusable, there may be legitimate use cases where someone wants to drop a callback system into a specific node of a workflow and not reuse the system anywhere else. In those cases, there is an unnecessary mutex locking being done each time the node is run.
We can avoid the mutex lock if we have two flavors of callbacks: unique and shared.
The text was updated successfully, but these errors were encountered: