Add exit handler which fires when Touch Portal exits with the plugin …#10
Add exit handler which fires when Touch Portal exits with the plugin …#10jaybz wants to merge 1 commit intotlewis17:developfrom
Conversation
|
I found an issue with this that will cause the plugin to die prematurely in certain cases. I'm looking for a solution for the issue. |
|
Turns out the issue isn't related to the code in this PR. The socket disconnects spontaneously regardless but I can't pin down what is causing it yet. Without knowing the cause, it may be possible to "fix" the issue by reconnecting the socket. |
|
On issue I had (that I have raised an issue for) was with the However if the problem came out after TouchPortal 2.3, there should not be many changes, but now the default is message type is utf8 without BOM. With BOM is default in .Net and will make issues (at least when I tried). I have not seen this issue you describe in my plugins, using "pure .Net sockets". |
I looked at the issue you raised. It doesn't seem similar to the disconnection issue, but I'll try it anyway. In any case, TCP connections should theoretically be treated as potentially unstable and disconnects should at least be expected and handled appropriately. In this case it looks like a reconnect might be the ideal behavior instead of just exiting. It's rather weird though that a connection to localhost would randomly disconnect. I'm beginning to think I have something else running that's causing this, but I have no idea what. |
|
As long as it does not go against localhost, I guess reconnect logic would make sense. Might be that something in a dependency messes with something like the |
|
Turns out the socket wasn't disconnecting on its own. Something else was generating an exception in my plugin and it was getting hidden by the indiscriminate exception catching in this API. This ends up causing an unnecessary disconnect of the socket. I haven't tracked down exactly where this is happening in the code, but this PR is completely unrelated. |
2 participants
This adds an exit handler which fires when Touch Portal exits with the plugin still running so that the plugin can quit gracefully.
This fixes an issue where the main plugin loop is not able to detect that Touch Portal has exited. It still requires the exit handler to terminate the plugin process, but otherwise, I haven't found a way to detect that the socket to Touch Portal is already closed.
I've used a separate PR for this so that it can be reviewed separately from the PR for API 3 additions. Hopefully, this doesn't cause any merge issues if/when both PRs gets merged.