Do not require mutability when operating on Device

[mrobinson]

No backend needs this to be mutable, so we can remove the mutability
qualifier from all implementations.

Signed-off-by: Martin Robinson mrobinson@igalia.com

[sagudev]

It's possible (but I have not checked) that we use &mut not for mutability but for exclusiveness, so that one cannot write the code wrong (otherwise we would need locks internally). So we needs to check if that is the case and if our api is still sound after this change.

[mrobinson]

Wouldn't that be possible by simply making sure that Sync isn't implementable?

[sagudev]

Wouldn't that be possible by simply making sure that Sync isn't implementable?

Not really if it would return types that would refer to lifetime of &mut, but that's not the case here so we only need to check if it's sound from multi threaded perspective. I think most stuff in surfman is not send/sync anyway (because of pointers) so this PR should be OK (I only did a quick glance).

[mrobinson]

Wouldn't that be possible by simply making sure that Sync isn't implementable?

Not really if it would return types that would refer to lifetime of &mut, but that's not the case here so we only need to check if it's sound from multi threaded perspective. I think most stuff in surfman is not send/sync anyway (because of pointers) so this PR should be OK (I only did a quick glance).

Yeah, at least on macOS, Device isn't Send, but this may depend on the platform itself.

[sagudev]

As far as I see this looks sound. Maybe @jdm should take another look, as I am not familiar with all surfman.

[mrobinson]

It's hard to see how removing unnecessary mutability qualifiers would cause the tests to start failing. I suspect that CI might be broken, unless I'm missing something here.

[sagudev]

Yes, CI is flaky, but we are currently having trouble with mac13 burn out so: #344