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

[Fred Hebert]

On 04/24, Robert Virding wrote:
> Strange because both user.erl and group.erl "should" be able to handle output requests in the middle of getting input. But it is a little difficult to see in group as there is all this tricky search code. :-)
> 
> Robert
> 

The big difference I see is really about an io_request that requires
more input coming directly to user. In most cases, things will be fine.

When we have shell.erl requesting data to user.erl, we enter an
io_request to fetch for content through io:scan_erl_exprs/3. This one
has a get_until io request, which makes the user.erl process enter
get_chars/7. This one, until it gets the 'eof' value it set itself
internally, will keep looping in get_chars/8. In this spot, I believe it
should still be able to serve IO reqs, except when it starts getting
data from the port, at which point, it enters get_chars_bytes/8, which
may end up calling get_chars_apply/7.

Once you enter this one, there's a possibility of having incomplete
data, prompting for a new state, which calls get_chars_more/7, which
selectively receives and ignores io requests and can go recursively.

I'm guessing (at a glance, haven't checked if it actually enters these
paths with the actual code) that this is where the blocking happens. In
fact, a quick try with process_info/1 shows me that it's where the
'user' proc gets stuck:

    (hi@REDACTED)10> process_info(whereis(user)).
    [{registered_name,user},
     {current_function,{user,get_chars_more,7}},
     {initial_call,{erlang,apply,2}},
     {status,waiting},
     {message_queue_len,1},
     {messages,[{io_request,<0.63.0>,<0.29.0>,
                            {put_chars,unicode,io_lib,format,["hey",[]]}}]},
     {links,[<0.6.0>,<0.28.0>,<0.33.0>,#Port<0.425>]},
     {dictionary,[{encoding,latin1},
                  {read_mode,list},
                  {shell,<0.33.0>}]},
      ...
     {suspending,[]}]

Looking at this, I'm guessing it would be possible to have a workaround
where get_chars_more/7 could listen to io_requests, but only if they are
for output -- otherwise you could get into nasty cases where you start
accepting other io requests that pull for data and things would get even
more confusing really fast and turn the handling of io events inside
out.

I'm thinking I recall seeing group.erl having a similar function that
could get locked up, but I haven't checked or tested to see if it was
indeed possible to lock it up in a similar way -- the fact that 'user'
is a distinct standalone group process makes the issue unlikely to
happen in the first place.

Regards,
Fred.