Support non-shared callbacks

Open
#16 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Stale
Tech stack
rust
Domain
backend

Research direction

Start by locating the callback implementation and the workflow node execution path. Trace how callbacks are reused and where the mutex is acquired, then determine the API and behavior needed for unique and shared callback flavors. Done means unique callbacks avoid unnecessary mutex locking while shared callbacks remain reusable across requests or workflows.

Written by the indexing model from the issue text.

Description

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.

Dominant language
Rust
Stars
75
Forks
18
Avg merge
12d 12h
Merged PRs (30d)
3

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from open-rmf/crossflow

All issues in open-rmf/crossflow

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.