Currently, when building observables, the default option is "safe", meaning that the observable is created with a locking structure (typically a ReentrantReadWriteLock or StampedLock) that protects the structure against concurrent modification by multiple threads.
This was a giant mistake. Including thread safety in the API was a good idea, but having it the default for each observable structure to have its own independent lock is a recipe for deadlock.
The thread safety API in the builders to all the structures need to be updated. The default needs to be thread-unsafe (which is fine for many applications), and specifying thread safety needs to take the form of supplying a locking structure to the builder instead of instructing it to make one itself. This will be more likely to make the user think harder about how thread safety needs to work in their application.
This extends to many of the collection structures in Qommons as well.
Currently, when building observables, the default option is "safe", meaning that the observable is created with a locking structure (typically a ReentrantReadWriteLock or StampedLock) that protects the structure against concurrent modification by multiple threads.
This was a giant mistake. Including thread safety in the API was a good idea, but having it the default for each observable structure to have its own independent lock is a recipe for deadlock.
The thread safety API in the builders to all the structures need to be updated. The default needs to be thread-unsafe (which is fine for many applications), and specifying thread safety needs to take the form of supplying a locking structure to the builder instead of instructing it to make one itself. This will be more likely to make the user think harder about how thread safety needs to work in their application.
This extends to many of the collection structures in Qommons as well.