[mobile] make Ready signal for custom listeners#3775
Conversation
This allows the caller to know when lnd is ready to accept RPC calls, which is inmportant for mobile applications where eveything happens in process.
Use the custom listeners' Ready channels to provide callbacks to the mobile application when the gRPC services are ready. NOTE: this changes the Start() API by adding one extra callback.
| callback.OnResponse([]byte("started")) | ||
| // Finally we start two go routines that will call the provided | ||
| // callbacks when the RPC servers are ready to accept calls. | ||
| go func() { |
There was a problem hiding this comment.
Maybe a simpler approach could be to modify lnd.Main() by adding a started channel as an incoming argument which then could be used to signal that all initialization is finished and we're waiting on <-signal.ShutdownChannel(). WDYT?
There was a problem hiding this comment.
Because the unlocker is conditional (it's only started if the wallet is actually locked) you need to know what the state of the individual servers is to be able to react. So there would need to be two started channels which basically comes down to the implemented solution.
I think this is probably the most simple you can get with the current architecture.
guggero
left a comment
guggero
left a comment
There was a problem hiding this comment.
Nice and simple change! This makes it much easier to embed lnd, not only on mobile 👍
| net.Listener | ||
|
|
||
| // Ready will be closed by the server listening on Listener. | ||
| Ready chan struct{} |
There was a problem hiding this comment.
Could we make this <-chan struct{} to make sure we only ever read from it?
There was a problem hiding this comment.
We can't really, since we are reading from it one place, and closing it the other place.
| callback.OnResponse([]byte("started")) | ||
| // Finally we start two go routines that will call the provided | ||
| // callbacks when the RPC servers are ready to accept calls. | ||
| go func() { |
There was a problem hiding this comment.
Because the unlocker is conditional (it's only started if the wallet is actually locked) you need to know what the state of the individual servers is to be able to react. So there would need to be two started channels which basically comes down to the implemented solution.
I think this is probably the most simple you can get with the current architecture.
3 participants
This allows the caller to know when lnd is ready to accept RPC calls,
which is important for mobile applications where everything happens in
process.
Fixes #3614