在io模块中，功能 io中有超时的唯一地方：wait_io_mon_reply / 2 它等待io请求消息的回复。为了确保客户端进程不会挂起，io进程已被监视，以检测在返回回复之前它死亡的情况。 io：wait_io_mon_reply / 2 必须处理可以接收的各种情况 AND 还可以清理消息队列，以防其发生多重返回，例如在监视关闭之前回复消息和进程死亡消息发送。由于erlang通信的非确定性的异步性质，这种情况发生并且必须被照顾。

The only place in the io module where there are timeouts in the function io:wait_io_mon_reply/2 where it waits for the reply to the io request message. To make sure the client process never hangs the io process has been monitored to detect the case where it dies before returning a reply. The io:wait_io_mon_reply/2 has to handle the various cases of what it can receive AND also clean-up the message queue in case it gets multiple returns, for example both a reply message and a process dying message send before the monitoring was turned off. Because of the non-deterministic asynchronous nature of erlang communication this happens and must be taken care of.

处理这种情况的标准方法是（直接从功能）：

The standard way of handling this is by doing (taken straight out of the function):

receive
    {io_reply, From, Reply} ->
        erlang:demonitor(Mref),
        receive 
            {'DOWN', Mref, _, _, _} -> true
        after 0 -> true
        end,
        Reply;

使用超时 0 意味着你永远不会如果消息不在，请等待，但是您会收到超时。我猜这是你在踪迹中看到的。这不是一个错误，而只是代码的编写方式。这样做没有可行的替代方法。

Using a timeout of 0 means you never wait if the message is not there but you do get a timeout. I am guessing that this is what you see in the trace. It is not an error but just way the code is written. There is no viable alternative to doing it this way.

这意味着在某种程度上你不得不忽略这个超时，或者只是接受超时作为自然的一部分程序而不是某种形式的异常或错误。

This means that in some way you will have to ignore this timeout, or perhaps just accept timeouts as a natural part of the program and not some form of "exception" or error.

如果我已经了解了它的工作原理。

If I have understood how it works.