yep

you will be able to. it is implemented in a way to have a proper multitreading reads and writes. but I am not sure you can easily do it at the moment as it requires some manual additional work right now. you will need to create a Frame object for every thread, I guess we will implement it to work automatically later

You can do it as long as you have a frame started for the current thread. The UI thread always has a frame, so you can always modify on the UI thread. If, for some reason your lambda is executed off the UI thread, you can see if you have a frame with

inFrame

, start one with

open()

and commit it with

commit()

(all in Frames.kt) Something like this should work: if (!inFrame) { open() // modify state commit() } else { // modify state // let whoever is managing the frame handle the commit }

We should rename frames to transactions or something :)

Yeah Frames just confused the heck out of me. What exactly is a frame?

Yep, naming of the API is bad and it should feel bad. Frame = transaction, like Romain said. Essentially, you want all of your changes to happen atomically, so when you

commit()

, all of the changes that you made to the models are considered as changed together.

Frames are in memory observable non-durable transactions which will be called transactions in the future, dropping the name frame entirely.

Did you folks considered batch updates to the tree? For example, when two or three coroutines update the tree almost simultaneously?

yes - and batching is currently the default

@Vladimir Ivanov Are you referring to the tree the composer is managing or a tree data-structure using

@Model

objects as nodes?