This is potentially something that should just go into #getting-started but I'll just ask here. I have a list that I search through and while I search through it, sometimes the list is updated. No issues, except for that the list is large and so it's "slow" and lags the UI. I wrapped it in a

withContext(Dispatchers.Default){

but now I get a

ConcurrentModificationException

. I could understand if I was adding/removing to the list on Dispatchers.Default while main thread was swapping the list entirely... but I'm just searching via

indexOfFirst

. thoughts?

regarding the default Java ArrayList implementation: it is not safe for concurrent read/write. all iterators are invalidated on any structural change.

Interesting. So I thought ConcurrentModException was multiple updates by different threads. but if my indexOfFirst is running in Dispatchers.Default, and so it's reading, while someone else is writing, then i guess it makes sense

it's not

Okay. Hm. not sure how to solve this then. Doing this search is taking a long time, so I tried to just wrap it in a withContext(Dispatchers.Default)

val indexOfPlace = appState.fullList.indexOfFirst { it.id == placeUid }

but it led to the CME. I wonder what the best thing to do here is. I really didn't think that reading a list while it's being modified would cause an issue.

it is an issue - list has no synchronization so any structural change can lead to an inconsistent read on another thread (imagine if elements are being shifted or the underlying array is reallocated)

Gotcha. Okay I'm gonna rethink my approach.

there are some (possible expensive) alternatives such as never modifying a list and publishing a new one on change, or using

CopyOnWriteArrayList

which (as the name implies) creates a copy on every modification, so existing iterators are not invalidated (although they will continue operating on a stale copy)

Gotcha. I'm not exactly sure how to proceed because basically the setup I have is that there are 10 items in a list. When a user selects an item, a long running operation happens and at the end of the operation, the original item in the list is updated. My issue shows up when a user clicks item 1, item 1 begins processing, then user selects item 2. It seems like I could try to cancel job 1 when user clicks item 2, but the info from job 1 is still valid and so having that job finish would be preffered.

yeah that's just not safe, regardless of Compose. you can only read a data structure in multiple threads if it's immutable or if it's known to be thread-safe (which List isn't)

you can only read a data structure in multiple threads if it's immutable or if it's known to be thread-safe (which List isn't)

TIL. I thought that you can red a data structure in multiple threads if you basically know when each thread is calling which. which in this case I thought that'd be safe because even though im switching threads, im trying to be procedural about the whole thing.

the list is immutable, we're replacing the reference with a different list on update

gotcha. so just technically speaking. i'm working around the issue by having a duplicate list (i.e. twice the memory used). right? am i following that?

well, sorta - there's both a map and list representation in there, which takes more space, but they are holding references to the same models, so if there's few changes then there's not that much allocation

esults in two lists (at least temporarily), each with a backing array of size (at least) 100, but there's only 100

SomeBigObject

instances across them

🤯 why hasn't that occurred to me? lol. okay cool. wow. so many TILs.

.toList()

there doesn't make a difference. it creates another copy, but that requires iterating and reading the list just the same as

.indexOfFirst

does, and will fail if the list is concurrently mutated

.toList()

there doesn't make a difference. it creates another copy, but that requires iterating and reading the list just the same as

.indexOfFirst

does, and will fail if the list is concurrently mutated

damn. maybe its just happening so quickly that its not triggering a CME in my testing. thanks for the heads up on that.

cancellation isn't immediate

gotcha. so the thing that's breaking my "logic" here is that im assuming cancellation is immediate. whoa boy. okay. your solution DEFINITELY sounds like the way to go then.

to clarify, it will be cancelled… eventually. it just won't be observed until it hits a suspend point

so ill just ask one more time here. My current code (as posted on stackoverflow). What's the minimal amount of change to get that working? It'd be this, right? 1. Change to

appState.fullListOfTodos

into a

MutableState<List<Model>>

2. Switch

//this search for index could take a long time, so move to CPU bound Dispatcher
                withContext(Dispatchers.Default) {
                

                  // The crash/exception happens on this line VVV
                  indexOfTodo =
                    appState.fullListOfTodos.indexOfFirst { it.id == todo.id }
                  place = appState.fullListOfTodos[indexOfTodo]

                  updatedTodo = TodoModel(//update a few fields)

                }
                // If I remove this line, the crash/exception does not happen VV
                appState.fullListOfTodos[indexOfTodo] = updatedTodo

to

withContext(Dispatchers.Default) {
                
                  indexOfTodo =
                    appState.fullListOfTodos.indexOfFirst { it.id == todo.id }
                  place = appState.fullListOfTodos[indexOfTodo]

                  updatedTodo = TodoModel(//update a few fields)

                  val newList = appState.fullListOfTodos.toMutableList().apply { this[indexOfTodo] = updatedTodo }
                  appState.fullListOfTodos = newList
                }

what is appState.fullListOfTodos? if it's not some sort of atomic reference then it's not necessarily safe (although it likely is ok in practice)

Agree with what you're saying. I guess I'm just moreso thinking "if Flows didn't exist, how would I do this. Should I just change my underlying data structure? etc" but yeah. ive learned so much with this. I can't believe its taken me so long to encounter a problem like this but i think its mostly due to the fact that ive probably dont crude searches like this on the main thread in the past... but now I have a pretty damn huge list so I was like "i know. ill just move it to dispatchers.Default" and im just in a world of pain because of that choice now. And so while I 100% agree that I should change my approach here, I am just curious if I can take my "working but slow" main thread approach and "easily" throw it onto a background thread.

unfortunately not as far as I know, I feel like it would be difficult to do in Java

gotcha. well. this was a whirlwind tour on things i thought i knew but I guess i didn't. i thought mutableState* in compose was actually immutable (adam powell once said that mutableState is actually imutable with a mutable facade) and so i thought that id be able to just update that whereever i please. i still dont get the coroutine cancellation isn't instant/immediate thing, but i will read into that as well. You solution of using a flow and a map is what I want to move to, but you use a bunch of apis there that I want to read about first before just converting my app to it (ie. folding, etc) Thanks @ephemient!!!! ❤️ ❤️ ❤️

looks like there's a proposal: https://openjdk.org/jeps/8208520

that IS cool. but yeah. a bit of a bummer that its been a few years. way to go finding it. I also think your last tldr of it makes a lot of sense to me.

copyFromItem and toModel aren't standard things, fill those in with your real implementation

Oh. Lmao

someFlow.runningFold(initial, transform)

is short for

flow {
    var accumulator = initial
    emit(accumulator)
    someFlow.collect { value ->
        accumulator = transform(accumulator, value)
        emit(accumulator)
    }
}

same as the Iterable extension by the same name

gotcha. I see launchIn and run because of this article. although I admittedly dont really understand it. ive just avoided it all this time since adam powell said this article was good https://www.billjings.net/posts/title/avoid-launchin/?up=technical