linux fork进程不继承,linux fork进程不继承

1)因为nginx的worker进程都是master进程fork出来的，继承了监听句柄。

2)nginx实现了一个锁，work进程竞争，谁获取锁，谁accept连接。######正解！######自己顶一下######

引用来自“火星人”的答案

1)因为nginx的worker进程都是master进程fork出来的，继承了监听句柄。

2)nginx实现了一个锁，work进程竞争，谁获取锁，谁accept连接。

不是使用select方法?

######类似 进程池######

引用来自“ZYud”的答案

引用来自“火星人”的答案

1)因为nginx的worker进程都是master进程fork出来的，继承了监听句柄。

2)nginx实现了一个锁，work进程竞争，谁获取锁，谁accept连接。

不是使用select方法?

工作进程的事件处理方式是可选的，在编译的时候配置即可，windows下用的是select，linux下默认用的是epoll或者kqueue。

######

引用来自“火星人”的答案

1)因为nginx的worker进程都是master进程fork出来的，继承了监听句柄。

2)nginx实现了一个锁，work进程竞争，谁获取锁，谁accept连接。

可是按道理说一个端口可是有一个应用的多个进程同时占用，但只能被一个进程所监听的呀！

一般情况下都是master进程负责监听，将任务分配给不同的子进程，即使是master进程fork出来的，也只是或得那个socket的句柄，也并未真正获得监听句柄吧！

追问一下：多个进程可以监听同一个端口，岂不是不同的应用可以监听同一个端口！

能帮我写个简单的c例子么？

######

引用来自“痞子汤”的答案

类似 进程池

进程池貌似跟这个是两码事儿吧

######

引用来自“火星人”的答案

1)因为nginx的worker进程都是master进程fork出来的，继承了监听句柄。

2)nginx实现了一个锁，work进程竞争，谁获取锁，谁accept连接。

对于第二点，如果他是这么实现的，岂不是性能是master进程负责监听分配任务的方式底，毕竟master的事儿没少做，还有资源竞争的代价在里面

######

多个进程可以监听同一个端口，岂不是不同的应用可以监听同一个端口！

两个完全独立的进程 ， 和 fork 出来的父子进程是有区别的吧。  再说我觉得和进程池有 点类似，图已经表明

在accept 之前你 fork 一堆子进程，在子进程内进行 accept 应该莫有问题吧

######个人理解