Android holds a lock on the buffer while it's in use, see #331, and I'm experimenting a bit with a similar design on macOS (which is to say, I think it's a reasonable thing for our buffers to do).
MutexGuards are not Send though, which makes me wonder if this is sound?
Is there a use-case for Buffer<'_> being Send? As-in, is there ever a case where you would want to present on a different thread than the one that called next_buffer()? The problem wouldn't exist if you moved the entire Surface to a different thread.
I can see the argument for buffers being Sync though (&mut T is Sync), it could maybe make sense to pass the buffer to a scoped thread and render in that.
Android holds a lock on the buffer while it's in use, see #331, and I'm experimenting a bit with a similar design on macOS (which is to say, I think it's a reasonable thing for our buffers to do).
MutexGuards are notSendthough, which makes me wonder if this is sound?Is there a use-case for
Buffer<'_>beingSend? As-in, is there ever a case where you would want to present on a different thread than the one that callednext_buffer()? The problem wouldn't exist if you moved the entireSurfaceto a different thread.I can see the argument for buffers being
Syncthough (&mut TisSync), it could maybe make sense to pass the buffer to a scoped thread and render in that.