Close stray process when stdio pipe is closed or possibly when parent process is killed (daemon flag?)

[nanoant]

This is continuation of the effort from:

1. Issue PSES needs to shutdown itself when it's supposed to #655 PSES needs to shutdown itself when it's supposed to
2. PR Close stray processes on exit #663 Close stray processes on exit

#655 was closed by @TylerLeonhardt as it was satisfied by PR #663. However I still believe we can easily get into the situation when LSP text editor that launches PSES gets killed and orphans the PSES process, that keeps running without a purpose. Actually this is the case with Sublime Text and LSP plugin, where other language LSP providers shutdown themselves when the Sublime Text quits without a need to use exit or any other means.

Therefore I propose 2 options for consideration (alternatives):

1. Introduce new -daemon flag, that unless specified, makes PSES to shutdown itself when the parent process disappears. This will make PSES behave like most of the command line tools, i.e. shutdown itself when the shell or launching process quits.

   The only purpose for PSES to run despite of parent process being alive or not is when it is it intended to be ran as a daemon, and I believe this intent should not be default (as it is now).

2. Shutdown itself when running as -stdio and when pipe is closed, as I was commenting in other ticket, there is no point running when pipe is closes, because there is nobody that will be able to issue exit and any other command anyways.

Thank you in advance for considering my suggestion. If you prefer I can try to get this behavior adapter myself and send the PR, but you (maintainers) may come to more elegant solution much quicker than me, therefore I post this issue first.

[rjmholt]

Really nice description and suggestions @nanoant.

I like both alternatives. It may be that (2) is simpler and less at risk of process leakage. I really like (1), but PSES has an anti-daemonic design currently; because it's so stateful, it really only makes sense bound to a specific session.

[rjmholt]

I noticed under the LSP spec for the initialize request it says:

If the parent process is not alive then the server should exit (see exit notification) its process.

That seems like another reasonable nudge toward (2).

[nanoant]

@rjmholt Thanks for finding this.
@SydneyhSmith Do you think this issues can be relabeled so it is now not "just" an Enhacement, but non-compatibility with specs?

[nanoant]

FYI I have currently worked around the problem with re-throwing stream termination exception, rather than gently consuming it. In this way ProtocolEndpoint task gets faulted when parents exits. It is far from perfect though.

diff --git a/src/PowerShellEditorServices.Protocol/MessageProtocol/ProtocolEndpoint.cs b/src/PowerShellEditorServices.Protocol/MessageProtocol/ProtocolEndpoint.cs
index ba52940..7dcc6d6 100644
--- a/src/PowerShellEditorServices.Protocol/MessageProtocol/ProtocolEndpoint.cs
+++ b/src/PowerShellEditorServices.Protocol/MessageProtocol/ProtocolEndpoint.cs
@@ -341,21 +341,21 @@ namespace Microsoft.PowerShell.EditorServices.Protocol.MessageProtocol
                 catch (IOException e)
                 {
                     // The stream has ended, end the message loop
                     Logger.Write(
                         LogLevel.Error,
                         string.Format(
                             "Stream terminated unexpectedly, ending MessageDispatcher loop\r\n\r\nException: {0}\r\n{1}",
                             e.GetType().Name,
                             e.Message));
 
-                    break;
+                    throw;
                 }
                 catch (ObjectDisposedException)
                 {
                     Logger.Write(
                         LogLevel.Verbose,
                         "MessageReader attempted to read from a disposed stream, ending MessageDispatcher loop");
 
                     break;
                 }
                 catch (Exception e)

[rjmholt]

We're actually moving toward an implementation based on https://github.com/OmniSharp/csharp-language-server-protocol, which is spec compliant. There's still much work to be done there, but that will resolve this