Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SES-1931] - Fix debouncer crash #1492

Merged
merged 1 commit into from
May 29, 2024

Conversation

simophin
Copy link

Description

The ConversationNotificationDebouncer doesn't handle threaded code correctly, added sync block manually.

This PR also makes sure no activity context is ever stored inside this singleton object.

Copy link

@bemusementpark bemusementpark left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, although there's probably a nice coroutine operator to collect and debounce.

@@ -5,9 +5,9 @@ import android.content.Context
import org.session.libsession.utilities.Debouncer
import org.thoughtcrime.securesms.ApplicationContext

class ConversationNotificationDebouncer(private val context: Context) {
class ConversationNotificationDebouncer(private val context: ApplicationContext) {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice

@simophin
Copy link
Author

LGTM, although there's probably a nice coroutine operator to collect and debounce.

I'd love to use Kotlin Flow in the hopefully not very far future

debouncer.publish { publish() }
}

private fun publish() {
for (threadID in threadIDs.toList()) {
val toNotify = synchronized(threadIDs) {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was just thinking, you can save the list copy by making it a var:

private fun publish() {
    synchronized(this) {
        threadIDs.also { threadIDs = mutableSetOf() }
    }.forEach {
context.contentResolver.notifyChange(DatabaseContentProviders.Conversation.getUriForThread(it), null)
}

but it needs the same synchronized(this) in notify.

Creating a new instance still needs an allocation, but toList needs an allocation and an O(n) copy. Probably negligible performance, so don't feel obliged to change it, but the syntax is nice-ish too.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I actually went down this path to avoid the copying and using AtomicReference to avoid synchronization but had since decided against it, as I think easier to read code is more important than a few nanoseconds off the hotspot.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also considered using a sorted long[] to avoid boxing but feel really unnecessary here, most of the time you only see a few items in the list really...

@bemusementpark bemusementpark merged commit 410e298 into oxen-io:dev May 29, 2024
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants