为什么Erlang适合软实时应用，而不适合硬实时？
或者也许它也适合硬实时？
Or maybe it's good for hard real-time too?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
或者也许它也适合硬实时？
Or maybe it's good for hard real-time too?
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（3）
Vincenzo Nicosia 在 2008 年有一个演讲，描述了 HRT erlang (HARTE) 的工作，其中还描述了当前 BEAM 的硬实时问题等。
看看 http://www.erlang.org/workshop/2007/proceedings /05nicosi.pdf
There is a presentation from 2008 by Vincenzo Nicosia describing work on HRT erlang (HARTE), which also describes the problems regarding hard real-time of the current BEAM, etc.
Have a look at http://www.erlang.org/workshop/2007/proceedings/05nicosi.pdf
垃圾收集可能会导致不可预测的持续时间的暂停；因此，您不能对延迟设置硬性上限。硬实时的定义基本上是你可以对延迟设置硬界限，所以这是一个问题。
Garbage collection can lead to pauses of unpredictable duration; as such, you can't put hard upper bounds on latency. The definition of hard real time is basically that you can set hard bounds on latency, so this is a problem.
哦，没有人回答为什么它对软实时有好处：
在 Erlang 中，每个进程都有自己的垃圾收集器。因此，如果每个进程都保留一个相当小的堆，那么 GC 暂停往往会非常小，这会提供非常好的实时行为。
Oh, nobody has answered why it is good for soft realtime though:
In Erlang, each process has its own garbage collector. So if the processes each are kept with a rather small heap, then GC pauses tend to be very small and this gives a really good realtime behaviour.