So I was reading through the Compose runtime code and while looking at `withMutableSnapshot` (which ...

# compose

[Filip Wiesner]

So I was reading through the Compose runtime code and while looking at withMutableSnapshot (which has been mentioned here several times) I saw a little note at the end of the doucmentation:

[block] must not suspend if [withMutableSnapshot] is called from a suspend function.

Why is that? 🤔 Is it because other code can be run on the same thread when the block suspends resulting in other unrelated part of the app being in this snapshot? I am not sure I know enough about Compose and Coroutines to be sure.

[Adam Powell]

Yes, it's driven by a form of ThreadLocal and we don't have a wiring from this API to a CoroutineContext-based management of it

[Adam Powell]

Any time we've looked at addressing this we confront the idea that the longer you leave a snapshot outstanding without committing it, the more likely it is that attempting to commit it can cause a conflict or involve out of date inputs that were frozen in time

[Adam Powell]

If you do need to take a snapshot and send it to another thread to do some work with it, you can do it with the lower level enter API

[Filip Wiesner]

I see, thanks for the quick response 👌

So would this be OK? (even though it doesn't really make sense)

var state by mutableStateOf(0)
val snap = Snapshot.takeMutableSnapshot()

snap.enter { state = 1 }

val result = suspendWhileGettingNumber()

snap.enter { 
    if (result > 5) state = result
}

snap.apply()

[Adam Powell]

Yes, that general pattern will work fine

[Adam Powell]

You'll also want to make sure you dispose it in a finally

[Adam Powell]

Snapshots will leak resources if not disposed