Afternoon guys, I have a bit of an code architecture question for embassy and am trying to work out the best approach.

I have two tasks which trigger the same action on a pin rising edge, like so:
```rust

#[embassy_executor::task]
pub async fn ppf_task(ppf: PPF) -> ! {
    let mut ppf = ExtiInput::new(ppf.interrupt, ppf.exti, Pull::Down);
    loop {
        ppf.wait_for_rising_edge().await;
        ... // do actions here
    }
```

However, the user can select which pin they want to use (as it is linked to different hardware but an FPGA in the middle converts each one into a simple high-low pulse). I don't want both tasks triggering, only one should, so I need a way to 'disable' and 'enable' the tasks.

Here are the potential options I have come up with:

1) A global static atomic flag for each task. There then becomes two loops, and outer loop that waits for that flag to be set, and the inner flag triggers the action and checks if the flag becomes unset. This seems simple enough to implement, but also requires a lot of flag checking on a high priority thread where low latency is important.

2) Refactor it into a single task, and have that task use a channel to receive a command to switch which pin to check for - This seems nice, but I then need to distribute a channel between multiple tasks, as this option can be changed via an inbuilt menu or via network configuration, so it gets a little messy.

3) Make my settings struct global behind a mutex so it can easily check - Seems like it will adda lot of unnecessary overhead for unlocking and locking the mutex, especially as its used in other places, and I don't care about race conditions for this particular setting but rust obviously (and correctly) will force you to use locking.

4) Dynamically spawn and kill the task: Is this even possible in embassy? I think the handle is given to the spawner so I would have no way of controlling that task or ending it early?


I appreciate this is a bit of a broad question, it essentially boils down to: How do you guys typically handle a user changing settings which affects things in other threads, preferably in a low-latency manner?