```@Composable @Deprecated("Example with bug") fun...
# compose
p
Copy code
@Composable
@Deprecated("Example with bug")
fun ListWithBug(myList: List<String>) {
    var items = 0

    Row(horizontalArrangement = Arrangement.SpaceBetween) {
        Column {
            for (item in myList) {
                Text("Item: $item")
                items++ // Avoid! Side-effect of the column recomposing.
            }
        }
        Text("Count: $items")
    }
}
I don't know why this code has thread-safe problem, can anyone explain ? https://developer.android.google.cn/jetpack/compose/mental-model#parallel
a
It's explained before:
Composable functions can run in parallel
This optimization means a composable function might execute within a pool of background threads.
Compose UI isn't multi-threaded now but it can be in the future.
p
Thanks for your answer,but in the above code, why does
items++
run on multiple threads?
items++
is not in a Composable, but just in a for-loop
z
If for loop can run parallel, then
items
is changed from multiple threads. Just use
forEachIndexed
I guess in that case.
p
Loop run parallel ? I don't think this is what Compose can do
a
ListWithBug
,
Row
,
Column
are all composables. The lambdas (
content
parameter) you passed to
Row
and
Column
are also composables.
p
But
items++
always run in one composable, so why thread unsafe ? I can understand if
items++
in the for loop is wrapped in a composable, but it isn't now
a
Text("Count: $items")
can be run in another thread.
p
So what the code wants to express is that
Text
and
Column
are parallel , not
items++
is parallel ?
Column
is inline right?it can't be in parallel with Text
a
I think the code is mainly intended to show that you should avoid side effects in your composables as it is incorrect even without multi-threaded composition. Multi-threaded composition just makes it "more" wrong.
☝️ 1
👌 1
As I said before,
The lambdas (
content
 parameter) you passed to 
Row
 and 
Column
 are also composables.
s
Author here. The intention is to show that each restart scope may be run on a new thread. So the write in column is not thread safe with the read in row
👍 1
That said there's not currently multithreading and both are scopes are now inline so actually triggering this fault with this code would be hard ☺️
But in general code of this style is unsafe in compose (due to regular var write in lambda capture)
While here, it's worth saying that writing a MutableState is thread safe
Is there another (very simple) example that'd show this better?
👏 1