Allow TCP client to reconnect in case of lost connection
We are doing "hot reload" of our go-astilectron-based app, where we basically keep the Electron process running while we restart the Go backend, and then re-connect it to the same running Electron process. This allows us to do a very nice in-place update of the app without having to restart it.
Previously, when the TCP server closes, Astilectron will force-quit Electron through process.exit(). With this commit, Astilectron will try to reconnect to the TCP server periodically. This doesn't impact regular close requests and signals.
On the Golang side, no changes are required. When re-starting, just use SkipSetup: true in the Astilectron options and skip the window.Create() step. This will re-use the same Window ID without issues.
Hey @asticode, thanks for the review. The changes you've requested have been done. I also made an additional change moving didReady = true to the end of the onReady function, as the IPC calls (like astilectron.sendMessage) would get delivered twice due to the callbacks being registered at each reconnection.
There's still one thing I'm tracking down, is that the windowClosed event is called twice after a reconnection. If you set a custom confirm dialog on window close event (WindowOptions.Custom.MessageBoxOnClose), it will display twice. I'll let you know once I patched that (or if you have any idea what would be the cause, that'd help :)).
Hey again @asticode :) Found out the issue. Readline was initialized twice on the socket during the first start, as both the onConnect and the regular code path were initializing, since didReady might not have been set yet.
Last commit (8bddfe2) changes this to initialize onReady in the onConnect callback. In our env, this seems to work fine, and since the connection should succeed anyway at some point, the backend being already there at that point, we should be good. Let me know if you want me to do it another way.