On Tue, 10 Feb 2026 13:49:13 +0100 Boris Brezillon <[email protected]> wrote:
> On Tue, 10 Feb 2026 10:15:04 +0000 > Alice Ryhl <[email protected]> wrote: > > > /// The owner of this value must ensure that this fence is signalled. > > struct MustBeSignalled<'fence> { ... } > > /// Proof value indicating that the fence has either already been > > /// signalled, or it will be. The lifetime ensures that you cannot mix > > /// up the proof value. > > struct WillBeSignalled<'fence> { ... } > > Sorry, I have more questions, unfortunately. Seems that > {Must,Will}BeSignalled are targeting specific fences (at least that's > what the doc and 'fence lifetime says), but in practice, the WorkItem > backing the scheduler can queue 0-N jobs (0 if no jobs have their deps > met, and N > 1 if more than one job is ready). Similarly, an IRQ > handler can signal 0-N fences (can be that the IRQ has nothing to do we > job completion, or, it can be that multiple jobs have completed). How > is this MustBeSignalled object going to be instantiated in practice if > it's done before the DmaFenceWorkItem::run() function is called? For the scheduler WorkItem (assuming a JobQueue model), it's kinda doable, because this is a FIFO, and we can get the first job in the queue (and thus the fence attached to this job) quite easily, but as soon as it's a post-execution WorkItem or IRQHandler, we never know when entering WorkItem::run()/ThreadedHandler::handle_threaded() which job will be completed (if any).
