risky_shell

[UAB L/K Peter Andersson]

Uffe,

The release note says: "The possibility to start the erlang shell in
parallell with the rest of the system has been reintroduced for
backwards compatibility. Note that this old behaviour is error prone and
should not be used unless for some reason necessary."

By being able to access the system from the shell early during startup,
it is easy to crash the system by mistake (since you can't tell what
state the system is in). We consider this an error and so in R10 we sync
the shell process with init so that it doesn't start until the system is
in a safe state.

You (i.e. AXD-301) requested we reintroduce the parallell pre-R10
behaviour (not as default, but to be activated by means of a flag). We
really didn't want to do this, but agreed because you insisted. Our
condition was that we could keep this an *undocumented* "feature" for
AXD-301 use only, hopefully (to be removed later when we'd implemented
better support for "early tracing"). You agreed you'd use this on your
own risk. ;-)

We have not documented the details because we don't want people to use
this flag and, like you, become dependent on the old shell startup
behaviour. So don't push me or I'll take away this flag of yours! :-)

The old parallell startup behaviour *could* be useful to start tracing
early. But since it is indeed parallell and the time to start the shell
process depends on e.g. io speed, it must be an unpredictable way to
start tracing an application start sequence.

  /Peppe


"Ulf Wiger (AL/EAB)" wrote:
> 
> Am I just blind, or is the command-line flag -risky_shell undocumented?
> 
> The stdlib release notes for OTP R10B_1 mention that there is a possibility to start the Erlang shell in parallel with the rest of the system, but there's no explanation of how this is done (fortunately, there's always the source code... :-)
> 
> Perhaps at least the release notes could mention the name of the flag that makes this possible, if you don't want the 'erl' documentation in ERTS to mention it?
> 
> The idea behind re-introducing this "bug" was that it is sometimes very important to be able to trace on the application start sequence. One convenient way of doing this is to simply enter calls to e.g. dbg in the shell.
> 
> /Uffe