Hitting X in RIDE client which has been connected to a running APL terminates the APL process too

[dyaandys]

Hit you hit X in the RIDE client, you get a MsgBox: "Quit Dyalog APL. Are you sure".

If you hit Yes then the RIDE client and the APL process terminate. The APL process should remain running.

IDE: Version: 4.0.2721 Platform: Win32 Date: 2017-03-08 10:51:17 +0100 Git commit: 27665044ec389ee453267a7333bac9fbb2ead66c Preferences:{ "favs":"[{\"type\":\"connect\",\"ssh_auth_type\":\"pass\",\"ssh_tnl_auth_type\":\"pass\",\"name\":\"debian7dev\",\"host\":\"debian7dev.dyalog.bramley\",\"port\":\"4502\"},{\"type\":\"connect\",\"ssh_auth_type\":\"pass\",\"ssh_tnl_auth_type\":\"pass\",\"name\":\"dfsaix\",\"host\":\"10.0.61.100\",\"port\":\"9003\"},{\"ssh_auth_type\":\"pass\",\"ssh_tnl_auth_type\":\"pass\",\"name\":\"mac0\",\"host\":\"mac0\"},{\"ssh_auth_type\":\"pass\",\"ssh_tnl_auth_type\":\"pass\",\"name\":\"local\",\"host\":\"127.0.0.1\",\"port\":\"9999\",\"type\":\"start\",\"exe\":\"C:\\Program Files\\Dyalog\\Dyalog APL-64 16.0 Unicode\\dyalog.exe\"},{\"ssh_auth_type\":\"pass\",\"ssh_tnl_auth_type\":\"pass\",\"name\":\"p7-61qa\",\"host\":\"p7-61qa\",\"port\":\"4503\"}]", "kbdLocale":"en_GB", "lineNums":"0", "selectedExe":"C:\Program Files\Dyalog\Dyalog APL-64 16.0 Unicode\dyalog.exe" }

Interpreter: Version: 16.0.29412 Platform: Linux Edition: Unicode/32 Date: Mar 8 2017 at 00:22:05

[e9gille]

This looks like an interpreter issue. It should only shut down when receiving a Disconnect message and it was spawned by RIDE.

[johndaintree]

I spoke to Jay about this. I think that RIDE should indicate if the interpreter should terminate or just disconnect. I can imagine cases where I'd want to spawn interpreters from RIDE, but leave them running after I've quite ride. Perhaps a parameter to the Disconnect message?

/JD

From: Gilgamesh Athoraya [mailto:notifications@github.com] Sent: 08 March 2017 15:50 To: Dyalog/ride ride@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Subject: Re: [Dyalog/ride] Hitting X in RIDE client which has been connected to a running APL terminates the APL process too (#122)

This looks like an interpreter issue. It should only shut down when receiving a Disconnect message and it was spawned by RIDE.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Dyalog/ride/issues/122#issuecomment-285078591 , or mute the thread https://github.com/notifications/unsubscribe-auth/AKU_CR5vGqHZDJYUqc8ct1TZRtfGNTZJks5rjs4cgaJpZM4MWotu . https://github.com/notifications/beacon/AKU_Cf9yvKI8bF9e6goSnAw8xfmsfRjjks5rjs4cgaJpZM4MWotu.gif

[jayfoad]

There is also a documented Exit message. How about we use Exit and Disconnect as follows:

If RIDE spawns an interpreter and the user closes RIDE:

1. RIDE sends Exit. The interpreter responds to this by initiating shutdown procedures (which might involve running APL destructors which write to the session, which causes further protocol traffic).
2. The interpreter sends Disconnect and then exit()s. The RIDE process will probably wait for its child process (the interpreter) to terminate before terminating.

If RIDE connects to a running interpreter and the user closes RIDE:

1. RIDE sends Disconnect and then terminates (or at least closes the connection).
2. (Or, in future, we could give the user the option of shutting down the interpreter, in which case RIDE will send Exit and wait for a Disconnect as above.)

If the user types )off into RIDE (regardless of how the interpreter was started):

1. The interpreter does its usual shutdown stuff but sends Disconnect just before exit()ing.

Note that in all cases Disconnect may not be necessary; instead of sending Disconnect you could just cleanly close the connection. Dunno if that's a good idea though. Could it interact badly with the interpreter's polling option (RIDE_INIT=poll::) ?

[dyaandys]

When RIDE sends Exit is the interpreter duty bound to terminate ? Could a customer’s destructor “hang” the terminate process ? Is there any need to consider this case, where presumably both RIDE and the invisible interpreter will need to be killed using O/S features ?

Otherwise sounds good to me, unless anyone can think of a use case where you would want a RIDE-spawned interpreter to carry on running even if the spawning RIDE is terminated.

A

From: jayfoad [mailto:notifications@github.com] Sent: 08 March 2017 16:23 To: Dyalog/ride Cc: dyaandys; Author Subject: Re: [Dyalog/ride] Hitting X in RIDE client which has been connected to a running APL terminates the APL process too (#122)

There is also a documented Exit message. How about we use Exit and Disconnect as follows:

If RIDE spawns an interpreter and the user closes RIDE:

1. RIDE sends Exit. The interpreter responds to this by initiating shutdown procedures (which might involve running APL destructors which write to the session, which causes further protocol traffic).
2. The interpreter sends Disconnect and then exit()s. The RIDE process will probably wait for its child process (the interpreter) to terminate before terminating.

If RIDE connects to a running interpreter and the user closes RIDE:

1. RIDE sends Disconnect and then terminates (or at least closes the connection).
2. (Or, in future, we could give the user the option of shutting down the interpreter, in which case RIDE will send Exit and wait for a Disconnect as above.)

If the user types )off into RIDE (regardless of how the interpreter was started):

1. The interpreter does its usual shutdown stuff but sends Disconnect just before exit()ing.

Note that in all cases Disconnect may not be necessary; instead of sending Disconnect you could just cleanly close the connection. Dunno if that's a good idea though. Could it interact badly with the interpreter's polling option (RIDE_INIT=poll::) ?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Dyalog/ride/issues/122#issuecomment-285089002 , or mute the thread https://github.com/notifications/unsubscribe-auth/AKkCErDyZza34Qb0OAYpHGQAXUue9YuUks5rjtX9gaJpZM4MWotu .Image removed by sender.

[mkromberg]

I think there is a use for "disconnect" from an interpreter even if it was spawned, but I think that needs to be a disconnect menu item or action - not something that you would normally do.

The interpreter side should be able to cope with losing the connection while in SERVE or POLL mode. However, we need that work done to set keep-alive so that disconnected sockets will always be detected.

[e9gille]

Could the dialog window have three buttons: quit, disconnect and cancel? Irrespective of how it was started a quit would issue the exit command and the interpreter would shut down. A disconnect would simply disconnect, potentially issuing a disconnect before closing the connection.

[jayfoad]

When RIDE sends Exit is the interpreter duty bound to terminate ? Could a customer’s destructor “hang” the terminate process ?

Dunno; I think the answer to questions like this is "it's the same as when you click the X to close the ODE".

Is there any need to consider this case, where presumably both RIDE and the invisible interpreter will need to be killed using O/S features ?

No, after RIDE sends Exit you will still have a perfectly normal interactive session, until RIDE receives the Disconnect. So if a destructor gets into an infinite APL loop you should be able to interrupt and debug it.

Otherwise sounds good to me, unless anyone can think of a use case where you would want a RIDE-spawned interpreter to carry on running even if the spawning RIDE is terminated.

I don't think we'd need anything extra in the protocol to allow that.

[jayfoad]

Could the dialog window have three buttons: quit, disconnect and cancel?

I agree with Morten that these (disconnecting from an interpreter you spawned, or quitting an interpreter you attached to) are not things you would normally do, and we should not make it easy to do them by accident.

[flouc001]

Fixed in interpreter 16.0.29830 and RIDE commit cac137241b5c2e3e3b7e017e8676c4bea9de6171.