Marcos Slomp

@soufianekhiat Please open a PR from your repo branch to merge into Halide main. It will make it easier for us to review, provide feedback, and even run the build/test...

@wolfpld I'd like to request reviews from @nosferalatu and @JamesMcCarthy44, but I can't seem to be able to add reviewers.

Also pinging @theblackunknown for a code review.

@wolfpld Please review the changes to the manual, and if it looks good to you, this PR is ready to merge!

For context, using the example of `halide_copy_to_device`, this is the lock that's been alluded: https://github.com/halide/Halide/blob/7356c6df9e2bfed9637183a2bd114ce8adba1de8/src/runtime/device_interface.cpp#L210 and these are the most "critical" places where `buf` needs to be inspected or altered:...

One possible solution would be to have a small "associative-set" of mutexes (mutices?) and obtain the corresponding mutex by looking-up into the set using the buffer pointer as a key....

We may just be overthinking and being overly pessimistic about concurrency issues here. If we look at the actual user interface: https://github.com/halide/Halide/blob/7356c6df9e2bfed9637183a2bd114ce8adba1de8/src/runtime/HalideRuntime.h#L1601-L1603 there's no mutual exclusion there in `set_flags`. Unless...

This should be "closeable" by now. Can someone verify?

Yes, I vouch for something like this. I did experiment locally with a similar feature (I called it "virtual threads"), and they are quite handy indeed (great for tracking asynchronous...

> active is not a solution, since it still produces a lot of data Are you sure? If the `active` argument is false, it's an early out and nothing gets...