Erlang原理2

进程组、任务和JCL（Process group, Jobs and JCL）


As Erlang evolved there was the idea that Erlang was, in many ways, like an operating system, not just a language running within an OS. One result of this way of thinking was that in one Erlang system you would want to run many separate applications concurrently. Each application would consist of a number of processes working together but sharing the basic Erlang system. As the applications were separate then there would be general “system” information that would be specific for each application but it should be able to be accessed in a common way.
随着Erlang的进化，在某种程度上它有点像一个操作系统，而不仅仅是运行在OS上的一门语言。这样导致在一个Erlang系统中你可能会想并行的运行许多单独的（互不相干的，separate）应用。每个应用由许多的进程组成，它们一起工作，一起分享基础Erlang系统。由于应用是互不相干的，每个应用应该都会有通用的“系统”信息，虽然每个应用都是特定的，但是每个应用应该能够用一种通用的方式访问。


To address this problem process groups were created. They are not the same as the UNIX concept of the same name. It was decided keep the flat, independent process structure which already existed, and still exists, and not impose a tree structure as exists in UNIX. This means that the process group is a much looser entity and in many ways completely transparent.
为解决这一问题创建了进程组。它们与同名的UNIX概念不同。我们决定保持平坦的（flat）、现有的（而且将来依然存在的）独立的进程结构，而不是像UNIX那样强加一个树形结构。这意味着进程组是一个更松散的实体（entity），在许多方面完全透明。

Each process has a ‘group leader’ which it inherits from the process which spawned it. A process group consists of all the processes which have the same group leader. The group leader is a normal process which has no a priori knowledge of the processes in its group. A process can change group simply by setting its ‘group leader’ to another process.
每个进程都有一个进程组组长（group leader），它从创建此进程的进程继承而来。一个进程组由所有有着相同group leader的进程组成。group leader是一个普通的进程，对它组里的进程它预先并没有太多的了解。一个进程可以改变它的组，只需简单的将它的group leader设置为另一进程即可。

Processes could then communicate with the group leader to get the process group’s common data.
进程可以与group leader通讯以获取进程组的共同数据。

There was much system information which could be “specialised” in this way; two obvious ones are default i/o streams and current working directory. Unfortunately this feature was never used to its full extent and is now only used for default i/o, the standard group leader process is an i/o-server process. Two reasons for it not being used is that the idea of running multiple applications on one Erlang system is not the common use (correct me if I am wrong) and the general lack of knowledge of the feature (again, correct me I am wrong).
采用这种方式会有许多系统信息成为特别（specialised）信息。最显而易见的两个是缺省I/O流和当前工作路径。不幸的是，此特征现在只在缺省I/O中用到，一个标准的group leader进程例子是I/O服务器进程。没有这样做有两个原因：在一个Erlang系统中运行多个应用并不常见（如果俺错了请帮忙指出）；普遍缺乏对特征的了解（再次的，如果俺错了请帮忙指出）。

It would be good to have some example programs that illustrate this ☺
这里最好有些例子程序说明这点。


Using process groups it is very easy for different applications to have different default i/o channels. For example some could be communicating through separate windows, some directly to a file and some over TCP to another system (a browser interface to Erlang).
通过使用进程组可以非常容易的使不同的应用有不同的缺省I/O通道。例如，一些应用可以通过独立的窗口（windows）通信，一些应用可以直接访问一个文件，一些应用可以通过TCP连接到其它系统（一个对Erlang的浏览器接口？？？）。

One problem with running multiple applications concurrently is that if more than one is communicating with the user through the same channel then the i/o will become very jumbled. 
并行的运行多个应用会有一个问题：如果有超过一个的应用通过相同的通道与用户通讯，I/O将变得非常混乱。

The solution to this was to introduce the concept of a ‘job’ and a user driver which controls which job is currently connected to, and hence communicating with, the user. A job is a process group together with its group leader. The user driver communicates the job through its group leader. Within the user driver you can start new jobs both locally and remotely, kill jobs and change which job is connected to the user. The i/o from jobs which are not connected is buffered (simply by not receiving it) until another job is connected and its i/o sent to the user. Controlling jobs in the user driver is done with JCL(Job Control Language).
解决办法是引进job和用户驱动器（user driver）的概念，user driver用来控制当前正在连接的是哪个job（以及正在与哪个用户通讯）。一个job是一个进程组及其group leader。user driver通过job的group leader与该job通信。在user driver内，你可以在本地也可以远程的启动新的jobs，或者杀掉jobs，以及修改由哪个job连接到用户。来自jobs的还没连接的I/O会被缓冲（通过不接受它），直到另一个job连接上，它的I/O会被发送给用户。通过JCL可以在user driver内控制jobs。

In the current implementation only new jobs running Erlang shells can be started but this is not an inherent limitation, any function could be spawned instead. In LFE(Lisp Flavoured Erlang, a new front end to Erlang with Lisp syntax) the user_drv module has a trivial extension which allows this.
目前的实现中只有运行在Erlang shell中的新jobs才能被启动，但这不是一个固有的限制，任意的函数可以在单独创建的进程中运行。在LFE(Lisp风格的Erlang, 一个新的有Lisp语法的Erlang前端语言)中，user_drv模块有一个扩展可以做到。