用CLion刷题遇到的不能同时存在多个main函数的问题

Posted 2023-05-13

参考技术A

参考： https://blog.cugxuan.cn/2019/11/01/Software/multi-main-func-run-in-clion/

最近开始用c++刷leetcode
发现在CLion中同时创建多个带有main函数的cpp文件会报错
上网查找了原因： https://blog.cugxuan.cn/2019/11/01/Software/multi-main-func-run-in-clion/
然后按照上面的解决方案尝试了一下：

1. 在cmake的txt文件中添加如下内容

2. 最初状态

3. 新增一个Leetcode0001.cpp文件

4. reload 一下项目

5. 编译， 完成！

124 IO模型

一、IO模型介绍

回顾：同步、异步、阻塞、非阻塞

同步： 指的是协同步调。既然叫协同，所以至少要有2个以上的事物存在。协同的结果就是：多个事物不能同时进行，必须一个一个的来，上一个事物结束后，下一个事物才开始。

异步：就是步调各异，就是多个事物，你进行你的，我进行我的，谁都不用管谁，所有的事物都在同时进行中

总结：同步就是多个事物不能同时开工，异步就是多个事物可以同时开工。

阻塞：由于执行任务过程中遇到了阻塞，导致任务执行不了，处于等待的状态

非阻塞：就是执行任务过程中没有遇到阻塞，进而可以一直执行任务

总结：回到程序里，阻塞同样意味着停下来等待，非阻塞表明可以继续向下执行。

1.阻塞I/O模型（blocking I/O）

2.非阻塞I/O模型（noblocking I/O）

3.I/O多道复用（I/O multiplexing）

4.信号驱动I/O（signal driven I/O）

5.异步I/O（asynchronous I/O）

前四个I/O都被称之为同步I/O

I/O发生时涉及的对象和步骤：对于一个network I/O （网络I/O）(这里我们以read举例)，它会涉及到两个系统对象，一个是调用这个I/O的process (or thread)，另一个就是系统内核(kernel)。当一个read操作发生时，该操作会经历两个阶段：

1. 等待数据准备 (Waiting data )
2. 将数据从内核拷贝到进程中(Copying data )

注意：以上两点和重要，因为在不同的I/O模型中，在以上两个阶段各有不同的情况

二、阻塞I/O模型

在linux中，默认情况下所有的socket都是blocking，一个典型的读操作流程大概是这样：

简单理解：就是用户进程在给服务端发送数据请求时，服务端可能不能立即给出返回数据，服务端要等待数据，这就造成了用户进程一直在原地等着，直到服务端数据准备好了，在将数据从自己内存中拷贝到用户内存中，然后用户进程接着执行做同日他的操作。

阻塞I/O特点：blocking I/O的特点就是在I/O执行的两个阶段（等待数据和拷贝数据两个阶段）都被block了。

实际上：几乎所有的I/O接口 ( 包括socket接口 ) 都是阻塞型的。这给网络编程带来了一个很大的问题，如在调用recv(1024)的同时，线程将被阻塞，在此期间，线程将无法执行任何运算或响应任何的网络请求。

2.1 解决方法（启用多线程/多进程）

在服务器端使用多线程（或多进程）。多线程（或多进程）的目的是让每个连接都拥有独立的线程（或进程），这样任何一个连接的阻塞都不会影响其他的连接。

2.2 该方法的问题

开启多进程或都线程的方式，在遇到要同时响应成百上千路的连接请求，则无论多线程还是多进程都会严重占据系统资源，降低系统对外界响应效率，而且线程与进程本身也更容易进入假死状态。

2.3 改进方案（线程池/进程池）

很多程序员可能会考虑使用“线程池”或“连接池”。“线程池”旨在减少创建和销毁线程的频率，其维持一定合理数量的线程，并让空闲的线程重新承担新的执行任务。“连接池”维持连接的缓存池，尽量重用已有的连接、减少创建和关闭连接的频率。这两种技术都可以很好的降低系统开销，都被广泛应用很多大型系统，如websphere、tomcat和各种数据库等。

2.4 改进后方案的问题

“线程池”和“连接池”技术也只是在一定程度上缓解了频繁调用I/O接口带来的资源占用。而且，所谓“池”始终有其上限，当请求大大超过上限时，“池”构成的系统对外界的响应并不比没有池的时候效果好多少。所以使用“池”必须考虑其面临的响应规模，并根据响应规模调整“池”的大小。

对应上例中的所面临的可能同时出现的上千甚至上万次的客户端请求，“线程池”或“连接池”或可以缓解部分压力，但是不能解决所有问题。总之，多线程模型可以方便高效的解决小规模的服务请求，但面对大规模的服务请求，多线程模型也会遇到瓶颈，可以用非阻塞接口来尝试解决这个问题。

三、非阻塞I/O模型

从图中可以看出，当用户进程向服务端发出请求数据时，如果服务端没有数据会立即给用户进程发送没有数据，此时，于是用户就可以在本次到下次再发起read询问的时间间隔内做其他事情，或者直接再次发送read操作。一旦服务端中的数据准备好了，并且又再次收到了用户进程的系统调用，那么它马上就将数据拷贝到了用户内存（这一阶段仍然是阻塞的），然后返回。

也就是说非阻塞的用户京城recvform系统调用调用之后，进程并没有被阻塞，内核马上返回给进程，如果数据还没准备好，此时会返回一个error。进程在返回之后，可以干点别的事情，然后再发起recvform系统调用。重复上面的过程，循环往复的进行recvform系统调用。这个过程通常被称之为轮询。轮询检查内核数据，直到数据准备好，再拷贝数据到进程，进行数据处理。需要注意，拷贝数据整个过程，进程仍然是属于阻塞的状态。所以，在非阻塞式I/O中，用户进程其实是需要不断的主动询问服务端数据准备好了没有。

3.1 非阻塞I/O实例

#服务端
import socket

server = socket.socket(socket.AF_INET,socket.SOCK_STREAM)
server.bind(('127.0.0.1',8080))
server.listen()
server.setblocking(False)#设置socket的接口为非阻塞,只要没人连服务端就报错

conn_lis = []
del_conn = []
while True:
    try: # 只要没客户端连就报错，所以捕捉异常
        conn,addr = server.accept()
        conn.lis.append(conn)
    except:
        for conn in conn_lis:
            try:# recv也是一个阻塞阶段，只要没人发数据就报错，所以捕捉异常
                msg = conn.recv(1024)
                if msg == b'':
                    del_conn.append(conn)
                    continue
                 print(msg)
                conn.send(b'byebye')
             except:pass
         for conn in del_conn:
            conn_lis.remove(conn)
            conn.close()
         del_conn.clear()  

#客户端
import socket
import time
from threading import thread
def action():
    while True:
        client = socket.socket()
        client.connect(('127.0.0.1',8080))
        client.send(b'hello')
        time.sleep(2)
        client.recv(1024)
        print(msg)
        client.close()
            
for i in range(20):
    t  = thread(target=action)
    t.start()

重要：非阻塞I/O模型绝不被推荐。

虽然能够在等待任务完成的时间里干其他活了（包括提交其他任务，也就是 “后台” 可以有多个任务在“”同时“”执行）。

1. 但是我们轮询的去调用recv会大大的提高cpu的占用率，导致效率变慢

2. 任务完成的响应延迟增大了，因为每过一段时间才去轮询一次read操作，而任务可能在两次轮询之间的任意时间完成。这会导致整体数据吞吐量的降低。

四、I/O多路复用

I/O multiplexing（I/O多路复用）用到了select/poll模块，是操作系统提供的一种机制，select/poll的好处就在于单个用户process就可以同时处理多个网络连接的I/O。它的基本原理就是select/poll会不断的轮询所负责的所有socket，当某个socket有数据到达了，就通知用户进程。它的流程如图：

当用户进程调用了select，那么整个进程会被阻塞，而同时，服务端会“监视”所有select负责的socket，当任何一个socket中的数据准备好了，select就会返回。这个时候用户进程再调用read操作，将数据从操作系统拷贝到用户进程。

这个图和blocking I/O(阻塞I/O)的图其实并没有太大的不同，事实上还更差一些。因为这里需要使用两个系统调用(select和recvfrom)，而blocking I/O只调用了一个系统调用(recvfrom)。但是，用select的优势在于它可以同时处理多个连接。

注意：

1. 如果处理的连接数不是很高的话，使用select/poll的web server不一定比使用multi-threading + blocking I/O的web server性能更好，可能延迟还更大。select/poll的优势并不是对于单个连接能处理得更快，而是在于能处理更多的连接。

2. 在多路复用模型中，对于每一个socket，一般都设置成为non-blocking，但是，如上图所示，整个用户的process其实是一直被block的。只不过process是被select这个函数block，而不是被socket I/O给block。

结论: select的优势在于可以处理多个连接，不适用于单个连接

4.1 select网络I/O模型

#服务端
import socket
import select

server = socket.socket(socket.AF_INET,socket.SOCK_STREAM)
server.bind(('127.0.0.1',8080))
server.listen()
server.setblocking(False)#设置socket的接口为非阻塞,只要没人连服务端就报错

re_lis = [server]
while True:
    r_lis,w_lis,x_lis = select.select(re_lis,[],[])
    for i in r_lis:
        if i == server:
            conn,addr = server.accept()
            re_lis.append(conn)
         else:
            try:
                msg = conn.recv(1024)
                if msg == b'':
                    conn.close()
                    re_lis.remove(conn)
                    continue
                print(msg)
                conn.send(b'byebye')
             except:pass

#客户端
import socket
import time
from threading import thread
def action():
    while True:
        client = socket.socket()
        client.connect(('127.0.0.1',8080))
        client.send(b'hello')
        time.sleep(2)
        client.recv(1024)
        print(msg)
        client.close()
            
for i in range(20):
    t  = thread(target=action)
    t.start()

4.2 epoll模型

select只在windows系统下用

pool可以在windows，linux下用

epoll只在linux下用

select/pool这两种机制，用法都是一样的：
但实际上这两种方法虽然都是可以解决我们的阻塞，由于这两种方法也都是利用了轮询的方式去处理阻塞的问题，所以当有很多个用户同时来访问服务端的时候，可能我第一个连接对象没有给我发送请求的时候，我顺延的执行了第二个连接对象的而请求，然后一直顺延下去，当有10000个连接对象的话，我就要等到10000个连接对象都执行完了，我才能回过头去处理第一个连接队形的请求
所以select和pool这种方法都因为轮询的原因造成了执行任务的效率降低

epoll模型由于它只能在linux下才能用，所以对我们python来说是比较可惜的但是我们python中也有一种机制叫做selectors 它可以帮我们自动选择该用那种模型，它实际上是通过回调函数来解决的

五、信号驱动I/O模型（了解）

以买票的例子举例，该模型小结为：

# 老王去火车站买票，给售票员留下电话，有票后，售票员电话通知老王，然后老王去火车站交钱领票。

# 耗费：往返车站2次，路上2小时，免黄牛费100元，无需打电话

由于信号驱动I/O在实际中并不常用，所以我们只做简单了解。

信号驱动I/O模型，应用进程告诉内核：当数据报准备好的时候，给我发送一个信号，对SIGI/O信号进行捕捉，并且调用我的信号处理函数来获取数据报。

六、异步I/O模型

以买票的例子举例，该模型小结为：

# 老王去火车站买票，给售票员留下电话，有票后，售票员电话通知老王并快递送票上门。

# 耗费：往返车站1次，路上1小时，免黄牛费100元，无需打电话

Linux下的asynchronous I/O其实用得不多，从内核2.6版本才开始引入。先看一下它的流程：

用户进程发起read操作之后，立刻就可以开始去做其它的事。而另一方面，从kernel的角度，当它受到一个asynchronous read之后，首先它会立刻返回，所以不会对用户进程产生任何block。然后，kernel会等待数据准备完成，然后将数据拷贝到用户内存，当这一切都完成之后，kernel会给用户进程发送一个signal，告诉它read操作完成了。

七、I/O模型比较分析

阻塞 vs 非阻塞:

调用 阻塞I/O 会一直block住对应的进程直到操作完成，

非阻塞I/O 在kernel还准备数据的情况下会立刻返回。

同步I/O 和 异步I/O 的区别:

定义：

同步I/O操作数/O n导致请求进程被阻塞，直到I/O操作数/O n完成为止;

异步I/O操作数/O n不会导致请求进程被阻塞;

区别：

同步I/O 做”I/O operatI/O n”的时候会将process阻塞，按照这个定义，四个I/O模型可以分为两大类，之前所述的 阻塞I/O ， 非阻塞I/O ，I/O多路复用 都属于 同步I/O 这一类，而 异步I/O 属于后一类。

有人可能会说， 非阻塞I/O 并没有被block啊。这里有个非常“狡猾”的地方，定义中所指的”I/O operatI/O n”是指真实的I/O操作，就是例子中的recvfrom这个system call。 非阻塞I/O 在执行recvfrom这个system call的时候，如果kernel的数据没有准备好，这时候不会block进程。但是，当kernel中数据准备好的时候，recvfrom会将数据从kernel拷贝到用户内存中，这个时候进程是被block了，在这段时间内，进程是被block的。

异步I/O ：当进程发起I/O操作之后，就直接返回再也不理睬了，直到kernel发送一个信号，告诉进程说I/O完成。在这整个过程中，进程完全没有被block。

各个I/O Model的比较如图所示：

经过上面的介绍，会发现 非阻塞I/O 和 异步I/O 的区别还是很明显的。在非阻塞I/O 中，虽然进程大部分时间都不会被block，但是它仍然要求进程去主动的check，并且当数据准备完成以后，也需要进程主动的再次调用recvfrom来将数据拷贝到用户内存。而 异步I/O 则完全不同。它就像是用户进程将整个I/O操作交给了他人（kernel）完成，然后他人做完后发信号通知。在此期间，用户进程不需要去检查I/O操作的状态，也不需要主动的去拷贝数据。

可以看出，以上五个模型的阻塞程度由低到高为：阻塞I/O>非阻塞I/O>多路转接I/O>信号驱动I/O>异步I/O，因此他们的效率是由低到高的。