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

[Stefan Zegenhagen]

Dear Robert,

> The shell might be trapping exits and ignore exit messages or running code which does the same. The minimal case: 
> 
> 1> process_flag(trap_exit, true).
> false
> 
> In which case the only guaranteed method to kill it is to send the kill signal. Unfortunately you cannot (must not) assume that code is well-behaved even if it has been written with the best intentions. Erlang's error handling mechanism is based on this assumption.

I fully agree with you. There's just two things that are difficult for
me to understand and indicate that a change to the current behaviour
might be necessary:

1) The error handling isn't consistently that rigorous. In my opinion,
it's the less critical path that uses the definite exit path, whereas
other exit paths simply assume that the client code is well-behaved.

2) Even for well-behaved code there is *ALWAYS* a penalty by not being
able to reliably retrieve the exit reason.

There may be solutions to the problem that satisfy all needs. Two spring
into my mind almost immediately:

a) Make the behaviour configurable by introducing an io:setopt() option,
but let the default behaviour as-is.

b) Assume that the code is well-behaved. Send a regular exit signal with
correct reason and check that the shell process really exits. If it does
not within a certain amount of time, forcedly kill it.



I would be willing to prepare a patch, but before doing so, I wanted to
get an overview of the possible solutions and which of them might be
acceptable to the erlang community.


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.