[erlang-questions] "New" vs. "old" console behavior: bug or feature?

[Scott Lystig Fritchie]

Fred Hebert <mononcqc@REDACTED> wrote:

fh> Input --> user.erl <---> shell.erl

fh> [...] The shell attempts to evaluate it, and if there's not enough
fh> data, it asks for more. user.erl then blocks until it can get more
fh> data to respond to the io request.

fh> When output is sent to 'user' it's sent as an additional io request,
fh> as a message. This message will not be read until the shell can
fh> answer the previous request. This is where you block.

Yup.

The combination of using "run_erl" + no tty/pty + lager prior to this
work(*) meant that any Erlang process that attempted to log a message
would be blocked arbitrarily until user.erl would return from
user:get_chars_more() et al.

If someone had used the Riak console recently, attaching to the VM's
console via "riak attach" (which in turn uses "to_erl"), and if the last
thing that they typed was not the end of an expression and then detached
from the console(**), every process that attempts to log a message
afterward will hang.  Forever.  Or until someone re-attaches to the
console and types "." and ENTER so that user.erl can finish its
simple-minded parsing.

The completely silent nature of the switch to the old shell was
baffling.  Not to mention causing us & our customers serious grief.  I
finally starting finding the root cause when I realized that all cases
of the all-lager-events-blocked-arbirarily mystery involved systems
where there was no 'user_drv' registered process.

-Scott

(*) https://github.com/basho/lager/pull/139

(**) Or if that person merely pressed ENTER before detaching, an
exceptionally easy thing to do.