Omri Mor

Pinging @DSMishler for additional comment.

> It seems like this issue and what it suggests may only handle my 3rd and 4th bullet points. Right, that's what it's tackling. Your points 1 and 2 are...

What I'm saying is that there _isn't_ a general solution. It is necessarily algorithm-dependent.

Related issues: #42, #43, #62, and #206

Regarding 1., this is fairly trivial to implement, albeit with some runtime synchronization cost, namely fetch-and-add atomics. I already do this in the LCI comm engine, for fine-grained communication event...

> it is not only about how to generate the unique ID, but also how to store it in the code in order to reuse it later on. Right—in the...

I'll note that I disagree with option 2, not because I think it'll be overly costly (though it might be), but because it changes the current semantics that cross-stream events...

Right—we either force the user to maintain ID uniqueness themselves for events that might match across streams i.e. ensuring that it _doesn't_ match in the current stream or events/event types...

Check out the `device_if` and `device_unless` condition [documentation](https://karabiner-elements.pqrs.org/docs/json/complex-modifications-manipulator-definition/conditions/device/)—I think you can do exactly what you want using that. It is admittedly more complicated than just a simple checkbox though, unfortunately....

The PaRSEC remote dependency model inherently relies on an assumption that the destination can reconstruct all (or at least the local) successors of a predecessor task. This enables the runtime...