Mobile: spin off blocking RPCConnection call into goroutine #61
Conversation
guggero
left a comment
guggero
left a comment
There was a problem hiding this comment.
Just a question about concurrency, otherwise looks good to me.
mobile/mobile.go
Outdated
| // Since the connection function is blocking, we need to spin it off | ||
| // in another goroutine here. See https://pkg.go.dev/syscall/js#FuncOf. | ||
| go func() { | ||
| mcMutex.Lock() |
There was a problem hiding this comment.
I'm not sure this changes the behavior that much. It's still a global lock, just narrower in its scope. If you want to have a lock per namespace, one way would be to have a map of mutexes (that itself is guarded by mMutex).
There was a problem hiding this comment.
@guggero Took this approach and pushed a change. LMK know what you think. Not sure if I have to explicitly check for each mutex here, but I included the check for now
kaloudis
force-pushed
the
mobile-connection-nonblocking
branch
from
5efa91c to
789f850
Compare
guggero
left a comment
guggero
left a comment
There was a problem hiding this comment.
Hmm, looking at it more closely this can be simplified by just putting the lock into the mobile client itself. It's easier to show in code, so this is my suggestion: guggero/lightning-node-connect@7f3323d
kaloudis
force-pushed
the
mobile-connection-nonblocking
branch
8 times, most recently
from
1859459 to
6ba220c
Compare
mobile: suggest improvements to locking
kaloudis
force-pushed
the
mobile-connection-nonblocking
branch
from
6ba220c to
1d483e8
Compare
|
Tested on both Android and iOS with multiple connections |
ellemouton
left a comment
ellemouton
left a comment
There was a problem hiding this comment.
LGTM! Just one small nit about embedding the mutex into the struct rather. But non-blocking :)
No description provided.