Erlang：什么时候产生一个新进程是合乎逻辑的？什么时候不呢？
如果我们有真正的重进程系统，其中进程生成是为了某种负载分配 - 这是很清楚的。
如果我们谈论网络服务器：为每个连接生成一个新进程是一个好主意，因为这样就可以进行分发。但还有什么？模型、视图和控制器的单一流程？听起来很奇怪，因为它们都以“线性”方式运行，因此不能很好地并行，我们只会在交换上获得开销。而且，那些“模型、视图和控制器”是如此之轻，所以它们可以留在一个进程中，不是吗？
那么，除了“新连接”情况之外，哪里有利于产生新进程。
谢谢你的建议。
If we have really heavy-processes system where process spawning is made for some kind of distribution of load - that's clear.
If we are talking about web-server : it's a good idea to spawn a new proccess for each connection, because then can be distributed. But what else? A single process for Model, View and Controller? Sounds strange, because they all run in a "liner" way, so it can not be good paralleled and we only get overhead on swapping. Also, those "Model, View and Controller" are so light, so they can stay in a single process, isn't it?
So, where is it good to spawn a new process excepting "new connection" situation.
Thank you in advice.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
一般来说，它是您需要管理共享资源的任何地方。它可能是一个套接字，或者一个数据库连接，但它也可能是一些共享的内存数据，或者某种状态机。
您可能还想对值列表进行并行处理（请参阅 pmap）。
对于您的“交换”点，您应该知道 Erlang 进程不使用 op-sys 设施进行调度，并且调度几乎是免费的。
在网络应用程序服务器的具体情况下，我理解你的问题。如果您正在编写一个共享状态很少的传统 Web 应用程序。您的 Web 框架可能已经处理缓存和会话状态等（这些设施将生成进程）。
我们都深深地被这种无状态 Web 应用程序模型所灌输。从小我们就被告知，有状态的系统很难开发，而且无法扩展。我想你会发现有些人正在挑战这一点。随着浏览器对 WebSockets 支持的改进，以及 Erlang 和 Clojure 等服务器端语言提供具有安全状态管理的可扩展平台，将会有人能够开发更具交互性的 Web 应用程序。举一个极端的例子，你能把 WoW 想象成一个 Web 应用程序吗？
In general, it's anywhere you have a shared resource to manage. It may be a socket, or a database connection, but it may also be some shared in-memory data, or a state machine of some kind.
You may also want to do parallel processing of a list of values (see pmap).
To your "swapping" point you should know that Erlang processes do no use op-sys facilities for scheduling, and scheduling is all but free.
In the specific case of a web-application server, I understand your question. If you are writing a conventional web application with very little share state. Your web framework probably already handles caching and session state and such (these facilities will spawn process).
We are all highly indoctrinated into this stateless web application model. We have all been told since we were pups the stateful systems are hard to develop and they don't scale. I think you will find that there are those that are challenging that. As browser support for WebSockets improve, and with server-side language like Erlang and Clojure providing scalable platforms with safe state management, there will be those who are able to make more interactive web-applications. As an extreme example, could you image WoW as a web application?
为每个连接生成一个新进程的原因之一是它使连接编程变得更加简单。由于一个进程仅处理一个连接，执行诸如阻塞访问数据库之类的操作，因此长轮询或流式传输变得更加容易。该进程阻塞不会影响任何其他连接。
在 Erlang 中，一般的“规则”是使用进程来建模并发活动并管理共享资源。流程是构建系统的基本方式。
One reason to spawn a new process for each connection is that it makes programming the connections much simpler. As a process only handles one connection doing things like having blocking access to data-bases, long polling or streaming becomes much easier. That this process blocks will not affect any other connections.
In Erlang the general "rule" is that you use processes to model concurrent activity and to manage shared resources. Processes are the fundamental way for structuring your system.