[erlang-questions] "New" vs. "old" console behavior: bug or feature?
Scott Lystig Fritchie
Wed Apr 24 22:39:36 CEST 2013
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.
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
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.
(**) Or if that person merely pressed ENTER before detaching, an
exceptionally easy thing to do.
More information about the erlang-questions