Closed andrewgazelka closed 2 years ago
Is there something hindering progress here? :) Would be super to get this and const generics support
Thanks! Didn't know about that website.
Can someone provide an example of an API that use closures to prevent memory corruption?
Probably something akin to crossbeam's scoped threads (scope
function).
I haven't seen any on the DMA side though, and not sure how useful it would be, i.e. you would only be able to do parallel work (w.r.t DMA) inside the "transfer closure", which wouldn't allow for doing work in different contexts (e.g. different interrupts / main). So maybe we should focus on being better suited for the common case, as #10 mentioned, it happened a few times that DMA implementations forgot to bound to 'static
.
A closure based transfer could probably create its own buffer wrapper too, so there's a workaround even for that case.
Can someone provide an example of an API that use closures to prevent memory corruption?
Probably something akin to crossbeam's scoped threads (
scope
function).I haven't seen any on the DMA side though, and not sure how useful it would be, i.e. you would only be able to do parallel work (w.r.t DMA) inside the "transfer closure", which wouldn't allow for doing work in different contexts (e.g. different interrupts / main). So maybe we should focus on being better suited for the common case, as #10 mentioned, it happened a few times that DMA implementations forgot to bound to
'static
.A closure based transfer could probably create its own buffer wrapper too, so there's a workaround even for that case.
ok, that makes sense.
@thalesfragoso @eldruin I'd really appreciate if this could get merged soon. Is there anything else you would like me to change? Thanks so much!
@eldruin done
@thalesfragoso are you also able to run the workflow? Thanks! :)
I am potentially concerned regarding a use case for non-static buffers in the previous docs in the embedded-dma:
Can someone provide an example of an API that use closures to prevent memory corruption? If closures have a valid use case, #18 might be a better option.