父进程则向node层暴露相关对象，如主设备的fd（通过该fd可以创建net.Socket对象进行数据双向传输），同时注册libuv的消息队列&baton->async，当子进程退出时触发&baton->async消息，执行pty_after_waitpid函数；
最后父进程通过调用uv_thread_create创建一个子进程，用于侦听上一个子进程的退出消息（通过执行系统调用wait4，阻塞侦听特定pid的进程，退出信息存放在第三个参数中），pty_waitpid函数封装了wait4函数，同时在函数末尾执行uv_async_send(&baton->async)触发消息。
在底层实现pty模型后，在node层需要做一些stdio的操作。由于伪终端主设备是在父进程中执行系统调用的创建的，而且主设备的文件描述符通过fd暴露给node层，那么伪终端的输入输出也就通过读写根据fd创建对应的文件类型如PIPE、FILE来完成。其实，在OS层面就是把伪终端主设备看为一个PIPE，双向通信。在node层通过net.Socket(fd)创建一个套接字实现数据流的双向IO，伪终端的从设备也有着主设备相同的输入，从而在子进程中执行对应的命令，子进程的输出也会通PIPE反应在主设备中，进而触发node层Socket对象的data事件。
此处关于父进程、主设备、子进程、从设备的输入输出描述有些让人迷惑，在此解释。父进程与主设备的关系是：父进程通过系统调用创建主设备（可看做是一个PIPE），并获取主设备的fd。父进程通过创建该fd的connect socket实现向子进程（从设备）的输入输出。 而子进程通过forkpty 创建后执行login_tty操作，重置了子进程的stdin、stderr和stderr，全部复制为从设备的fd（PIPE的另一端）。因此子进程输入输出都是与从设备的fd相关联的，子进程输出数据走的是PIPE，并从PIPE中读入父进程的命令。详情请看参考文献之forkpty实现
另外，pty库提供了伪终端的大小设置，因此我们通过参数可以调整伪终端输出信息的布局信息，因此这也提供了在web端调整命令行宽高的功能，只需在pty层设置伪终端窗口大小即可，该窗口是以字符为单位。
web终端安全性保证
基于glibc提供的pty库实现伪终端后台，是没有任何安全性保证的。我们想通过web终端直接操作服务端的某个目录，但是通过伪终端后台可以直接获取root权限，这对服务而言是不可容忍的，因为它直接影响着服务器的安全，所有需要实现一个：可多用户同时在线、可配置每个用户访问权限、可访问特定目录的、可选择配置bash命令、用户间相互隔离、用户无感知当前环境且环境简单易部署的“系统”。
最为适合的技术选型是docker，作为一种内核层面的隔离，它可以充分利用硬件资源，且十分方便映射宿主机的相关文件。但是docker并不是万能的，如果程序运行在docker容器中，那么为每个用户再分配一个容器就会变得复杂得多，而且不受运维人员掌控，这就是所谓的DooD（docker out of docker）-- 通过volume “/usr/local/bin/docker”等二进制文件，使用宿主机的docker命令，开启兄弟镜像运行构建服务。而采用业界经常讨论的docker-in-docker模式会存在诸多缺点，特别是文件系统层面的，这在参考文献中可以找到。因此，docker技术并不适合已经运行在容器中的服务解决用户访问安全问题。