[erlang-bugs] Strange thing in lib/kernel/src/group.erl

[Fred Hebert]

Hi,

The reason I could see to have exit_shell(kill) (which in turn calls
exit/2 on the shell iff a shell is attached) is that you want, out of
all doubt, to get rid of the shell.

The group.erl module is entirely distinct from the shell implementation.
For example, most shells use shell.erl, but the one used by the SSH
daemon has a custom one going that's different, and there are also
concepts such as safe shells.

In the event that some shell implementation traps exits (and they
shoulda be expected to do so if they want to handle the 'interrupt'
signal, which is necessary to deal with some ^G commands such as 'i', in
any special manner), if the shell is currently blocked in an IO request,
it will *never* see the 'EXIT' signal given it is busy waiting on
another message, namely the IO Request's response.

Because of this specific reason, it might be necessary to kill the
shell with the 'kill' signal, which cannot be trapped. We just can't
assume that the other shell will receive it.

Now granted, I think it could be possible to send both exit signals
there (exit_shell(R), exit_shell(kill), exit(R)) just in case in order
to allow more obvious exit messages, but I'm not sure it would
necessarily be worth it. Someone from the OTP team (or Robert) could
voice their opinion there.

Regards,
Fred.

On 05/03, Stefan Zegenhagen wrote:
> Dear all,
> 
> I've stumbled across a small issue in the implementation of the process
> group server.
> 
> The code in group.erl spawns a server process that monitors the exit of
> either the shell and the user_drv that started it. In the regular
> server_loop, exits of the user_drv (Drv) are handled as follows:
> 
>   receive
>   ...
>   {'EXIT',Drv,R} ->
>       exit(R);
> 
> 
> When a blocking io_request is being executed, the following code is
> executed instead:
> 
>   %% 'kill' instead of R, since the shell is not always in
>   %% a state where it is ready to handle a termination
>   %% message.
>   exit_shell(kill),
>   exit(R)
> 
> Besides the behaviour being inconsistent, it also means that our shell
> process monitor receives the 'killed' exit reason more often than the
> real exit reason, which defeats our custom error handling and logging.
> 
> Looking at the comment above the exit_shell(kill) statement, there seems
> to have been a reason to put it there at some time. Looking at the code
> in the io module that does those io_requests, it should not be
> necessary.
> 
> I'm unsure whether it is safe to remove the exit_shell(kill) statement
> or whether something would terribly break. However, not receiving the
> correct exit reason does give us a headache.
> 
> 
> Kind regards,
> 
> -- 
> Dr. Stefan Zegenhagen
> 
> arcutronix GmbH
> Garbsener Landstr. 10
> 30419 Hannover
> Germany
> 
> Tel:   +49 511 277-2734
> Fax:   +49 511 277-2709
> Email: stefan.zegenhagen@REDACTED
> Web:   www.arcutronix.com
> 
> *Synchronize the Ethernet*
> 
> General Managers: Dipl. Ing. Juergen Schroeder, Dr. Josef Gfrerer -
> Legal Form: GmbH, Registered office: Hannover, HRB 202442, Amtsgericht
> Hannover; Ust-Id: DE257551767.
> 
> Please consider the environment before printing this message.
> 
> _______________________________________________
> erlang-bugs mailing list
> erlang-bugs@REDACTED
> http://erlang.org/mailman/listinfo/erlang-bugs