1.本发明涉及信息通信
技术领域：
：，尤其涉及一种阻塞式事件通知方法及装置。
背景技术：
：：2.数据中心服务器运行的传统网络应用主要通过linux内核来监听并获取新事件，为了对linux内核的协议栈进行优化，基于高性能数据包收发框架开发的用户态协议栈应运而生。3.然而，对于用户态协议栈来说，由于用户态协议栈和应用程序同时运行在用户态，用户态协议栈没有权限阻塞或唤醒应用程序，导致用户态协议栈提供的用户态事件聚合通知等待接口无法支持阻塞式语义。技术实现要素：4.本发明提供一种阻塞式事件通知方法及装置，用以解决现有技术中用户态事件聚合通知等待接口无法支持阻塞式语义的缺陷。5.第一方面，本发明提供一种阻塞式事件通知方法，该方法包括：6.根据应用程序发起的第一接口调用请求，向接口兴趣队列中添加待监听文件，并将为网络套接字的待监听文件添加至用户态协议栈的监听队列中；7.根据应用程序发起的第二接口调用请求，判断所述接口兴趣队列中是否有网络套接字，在所述接口兴趣队列中有网络套接字，且所述用户态协议栈的监听队列中待监听文件无待通知事件时，创建先入先出队列；其中，所述先入先出队列中无待通知事件；8.对所述先入先出队列进行监听，根据监听结果，使应用程序进入阻塞状态或唤醒状态；9.在应用程序进入唤醒状态时，向应用程序发送待通知事件。10.根据本发明提供的阻塞式事件通知方法，对所述先入先出队列进行监听，根据监听结果，使应用程序进入阻塞状态或唤醒状态，包括：11.通过内核态接口监听所述先入先出队列；12.若所述先入先出队列无待通知事件，则通过所述内核态接口使应用程序进入阻塞状态；13.若所述用户态协议栈的监听队列中所述待监听文件有待通知事件，则改变所述先入先出队列的当前状态，以向操作系统内核发出结束阻塞指令；14.所述操作系统内核用于通过所述内核态接口接收所述结束阻塞指令，根据所述结束阻塞指令使应用程序结束阻塞并进入唤醒状态。15.根据本发明提供的阻塞式事件通知方法，向接口兴趣队列中添加待监听文件之后，还包括：16.将为非网络套接字的待监听文件添加至内核的监听队列中。17.根据本发明提供的阻塞式事件通知方法，还包括：18.根据应用程序发起的第二接口调用请求，判断所述接口兴趣队列中是否有网络套接字，在所述接口兴趣队列中无网络套接字，且所述内核的监听队列中所述待监听文件无待通知事件时，通过内核态接口使应用程序进入阻塞状态。19.根据本发明提供的阻塞式事件通知方法，在所述接口兴趣队列中无网络套接字，且所述内核的监听队列中所述待监听文件无待通知事件时，通过内核态接口使应用程序进入阻塞状态之后，还包括：20.若所述内核的监听队列中所述待监听文件有待通知事件，则通过所述内核态接口唤醒应用程序；21.向应用程序发送所述待通知事件。22.根据本发明提供的阻塞式事件通知方法，所述内核态接口为内核态事件聚合通知等待接口。23.根据本发明提供的阻塞式事件通知方法，所述第一接口调用请求为对第一用户态接口的调用请求，所述第一用户态接口为用户态事件聚合通知控制接口；24.所述第二接口调用请求为对第二用户态接口的调用请求，所述第二用户态接口为用户态事件聚合通知等待接口。25.第二方面，本发明还提供一种阻塞式事件通知装置，该装置包括：26.第一处理模块，用于根据应用程序发起的第一接口调用请求，向接口兴趣队列中添加待监听文件，并将为网络套接字的待监听文件添加至用户态协议栈的监听队列中；27.第二处理模块，用于根据应用程序发起的第二接口调用请求，判断所述接口兴趣队列中是否有网络套接字，在所述接口兴趣队列中有网络套接字，且所述用户态协议栈的监听队列中待监听文件无待通知事件时，创建先入先出队列；其中，所述先入先出队列中无待通知事件；28.第三处理模块，用于对所述先入先出队列进行监听，根据监听结果，使应用程序进入阻塞状态或唤醒状态；29.通知模块，在应用程序进入唤醒状态时，向应用程序发送待通知事件。30.第三方面，本发明还提供一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现如上述任一种所述阻塞式事件通知方法的步骤。31.第四方面，本发明还提供一种非暂态计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现如上述任一种所述阻塞式事件通知方法的步骤。32.本发明提供的阻塞式事件通知方法及装置，通过向接口兴趣队列中添加待监听文件，并确定待监听文件的监听队列，在接口兴趣队列中有网络套接字，且用户态协议栈的监听队列中待监听文件无待通知事件时，创建先入先出队列，对先入先出队列进行监听，根据监听结果，使应用程序进入阻塞状态或唤醒状态，从而使用户态事件聚合通知等待接口能够支持阻塞式语义，提高了用户态协议栈对现有应用程序的兼容性。附图说明33.为了更清楚地说明本发明或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。34.图1是本发明提供的阻塞式事件通知方法的流程示意图之一；35.图2是本发明提供的阻塞式事件通知方法的流程示意图之二；36.图3是本发明提供的阻塞式事件通知方法的流程示意图之三；37.图4是本发明提供的阻塞式事件通知方法的流程示意图之四；38.图5是本发明提供的阻塞式事件通知装置的结构示意图；39.图6是本发明提供的电子设备的结构示意图。具体实施方式40.为使本发明的目的、技术方案和优点更加清楚，下面将结合本发明中的附图，对本发明中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。41.首先对本发明针对的技术背景和现有的事件通知方法存在的不足进行详细说明。42.数据中心服务器运行的传统网络应用，主要通过linux内核来监听并获取新事件，linux内核主要存在以下两大问题：43.第一，对用户来说，随着高速网卡和多核cpu的不断发展，linux内核的网络协议栈成为主要的性能瓶颈，无法满足当前网络应用的高性能网络流量处理需求；44.第二，对开发者来说，由于牵涉到操作系统内核，新功能调试难，开发周期长。因此，自从linux诞生之日起，对于内核的改进就一直在进行。45.针对linux内核进行优化的方案中，高性能数据包收发(input/output，i/o)框架，如inteldpdk、netmap等，虽然极大提高了数据收发性能，但是这些高性能数据包i/o框架本身并没有提供完整的事件聚合通知机制，阻碍了其在业界的广泛使用。46.基于高性能数据包i/o框架开发的用户态协议栈，例如mtcp、ix等，虽然具有较高的性能，但是其提供的应用程序接口(applicationprogramminginterface，api)与可移植操作系统接口(portableoperatingsysteminterfaceforunix，posixapi)的语义和功能不同，不能完全兼容现有应用程序。47.操作系统内核提供的内核态事件聚合通知等待接口是高性能网络应用常用的api之一，应用程序通过调用该接口，可以监听网络套接字(socket)、先入先出队列(firstinfirstout,fifo)等多种类型文件的新事件。当无新事件时，操作系统内核可以让应用程序进入阻塞状态，节约cpu资源。当新事件到来时，操作系统内核可以唤醒应用程序读取新事件。48.然而，对于用户态协议栈来说，由于用户态协议栈和应用程序同时运行在用户态，用户态协议栈没有权限阻塞或唤醒应用程序，导致用户态协议栈提供的用户态事件聚合通知等待接口无法支持阻塞式语义。49.另外，由于现有用户态协议栈主要负责网络数据的收发，其提供的用户态事件聚合通知等待接口仅支持监听网络套接字的新事件而不支持监听其他类型文件的新事件。50.这些不足限制了用户态协议栈对现有应用程序的兼容性，提高了将现有应用程序移植到用户态协议栈上的难度。51.为此，本发明对现有的用户态阻塞式事件通知方法进行改进，下面结合图1-图6描述本发明实施例提供的阻塞式事件通知方法及装置，以及应用该方法的电子设备。52.图1示出了本发明实施例提供的阻塞式事件通知方法，该方法包括：53.步骤110：根据应用程序发起的第一接口调用请求，向接口兴趣队列中添加待监听文件，并将为网络套接字的待监听文件添加至用户态协议栈的监听队列中。54.更优地，向接口兴趣队列中添加待监听文件之后，还可以包括：55.将为非网络套接字的待监听文件添加至内核的监听队列中。56.在示例性实施例中，参见附图2，向接口兴趣队列中添加待监听文件，并确定待监听文件的监听队列的过程，具体可以包括：57.步骤210：若应用程序调用第一用户态接口；58.步骤220：将待监听文件的文件描述符添加至接口兴趣队列中；59.步骤230：判断待监听文件是否为网络套接字(socket)；60.步骤240：若是，则将待监听文件的文件描述符添加至用户态协议栈的监听队列中；61.步骤250：若否，则将待监听文件的文件描述符添加至内核的监听队列中。62.需要说明的是，本实施例中第一接口调用请求为对第一用户态接口的调用请求，第一用户态接口可以是用户态(阻塞式)事件聚合通知控制接口epoll_ctl()，应用程序调用该接口时，可以发起添加待监听文件的请求，进而可以将待监听文件的文件描述符添加至epoll兴趣队列(即接口兴趣队列)中。63.本实施例可以添加多个待监听文件，进而可以同时监听多个感兴趣文件，从而后续能够实现阻塞式事件的聚合通知。64.可以理解的是，本实施例中待监听文件可以是用于传输数据的网络文件，此时该待监听文件的事件可以是读事件或者写事件。65.步骤120：根据应用程序发起的第二接口调用请求，判断接口兴趣队列中是否有网络套接字，在接口兴趣队列中有网络套接字，且用户态协议栈的监听队列中待监听文件无待通知事件时，创建先入先出队列；其中，先入先出队列中无待通知事件。66.需要说明的是，本实施例中第二接口调用请求为对第二用户态接口的调用请求，第二用户态接口可以是用户态(阻塞式)事件聚合通知等待接口epoll_wait()。67.步骤130：对先入先出队列进行监听，根据监听结果，使应用程序进入阻塞状态或唤醒状态。68.在示例性实施例中，对先入先出队列进行监听，根据监听结果，使应用程序进入阻塞状态或唤醒状态的过程，具体可以包括：69.通过内核态接口监听先入先出队列；70.若先入先出队列无待通知事件，则通过内核态接口使应用程序进入阻塞状态；71.若用户态协议栈的监听队列中待监听文件有待通知事件，则改变先入先出队列的当前状态，以向操作系统内核发出结束阻塞指令；72.操作系统内核用于通过内核态接口接收结束阻塞指令，根据结束阻塞指令使应用程序结束阻塞并进入唤醒状态。73.考虑到实际应用过程中，只有操作系统内核才能直接使应用程序进入阻塞或唤醒状态，本实施例中用户态协议栈通过调用内核态接口，可以间接地使应用程序进入阻塞或唤醒状态，进而使得用户态协议栈提供的用户态事件聚合通知等待接口可以支持阻塞式语义。74.步骤140：在应用程序进入唤醒状态时，向应用程序发送待通知事件。75.更优地，本实施例提供的阻塞式事件通知方法，还可以包括：76.根据应用程序发起的第二接口调用请求，判断接口兴趣队列中是否有网络套接字，在接口兴趣队列中无网络套接字，且内核的监听队列中待监听文件无待通知事件时，通过内核态接口使应用程序进入阻塞状态。77.进一步地，在接口兴趣队列中无网络套接字，且内核的监听队列中待监听文件无待通知事件时，通过内核态接口使应用程序进入阻塞状态之后，还可以包括：78.若内核的监听队列中待监听文件有待通知事件，则通过内核态接口唤醒应用程序；79.向应用程序发送待通知事件。80.需要说明的是，本实施例中内核态接口可以是内核态(阻塞式)事件聚合通知等待接口kernel_epoll_wait()。81.本实施例针对的第一用户态接口、第二用户态接口以及内核态接口均指的是阻塞式接口，是指在未监听到感兴趣文件的新事件时,即没有需要向应用程序通知的事件时，就使应用程序进入阻塞状态,等待新事件的到来。而对于非阻塞式接口，则没有上述等待环节。82.参见附图3，在应用程序调用用户态事件聚合通知等待接口epoll_wait()时，本实施例提供的阻塞式事件通知方法，具体执行以下流程：83.步骤310：在应用程序调用第二用户态接口时，即调用用户态事件聚合通知等待接口epoll_wait()；84.步骤320：判断epoll兴趣队列(即接口兴趣队列)中是否有网络套接字；85.步骤330：若epoll兴趣队列中有网络套接字，则判断用户态协议栈的监听队列中待监听文件是否已有新事件(即待通知事件)；86.若有新事件，则执行步骤390；87.若没有新事件，则执行步骤340：创建fifo(firstinputfirstoutput，先入先出队列)；88.步骤350：调用内核态事件聚合通知等待接口kernel_epoll_wait()监听先入先出队列，此时先入先出队列中无新事件；89.步骤360：内核态事件聚合通知等待接口kernel_epoll_wait()使应用程序进入阻塞状态，以等待新事件；90.步骤370：若epoll兴趣队列中没有网络套接字，则调用内核态事件聚合通知等待接口kernel_epoll_wait()；91.步骤380：判断内核的监听队列中的待监听文件是否已有新事件(即待通知事件)，若有新事件，则执行步骤390；若没有新事件，则执行步骤360；92.步骤390：返回新事件给应用程序，事件通知流程结束。93.参见附图4，当新事件到来时，本实施例提供的阻塞式事件通知方法，具体执行以下流程：94.步骤410：当内核的监听队列中的待监听文件有新事件(即待通知事件)时，依次执行步骤440和步骤450；95.步骤420：当用户态协议栈的监听队列中待监听文件有新事件时，依次执行步骤430、步骤440和步骤450；96.步骤430：改变先入先出队列的当前状态，具体可以通过用户态协议栈将任意字符写入先入先出队列中，比如用户态协议栈可以通过将“1”写入先入先出队列中以产生一个新事件；97.步骤440：通过内核态事件聚合通知等待接口kernel_epoll_wait()结束阻塞，使操作系统内核唤醒应用程序；98.步骤450：通过用户态事件聚合通知等待接口epoll_wait()将新事件返回给应用程序。99.这样的话，通过创建先入先出队列，利用先入先出队列与内核态事件聚合通知等待接口配合，能够实现对应用程序阻塞状态和唤醒状态的控制，可以解决传统事件通知过程中，用户态协议栈没有权限阻塞或唤醒应用程序，导致用户态协议栈提供的用户态事件聚合通知等待接口无法支持阻塞式语义的问题。100.同时，本实施例提供的方法中待监听文件既可以是网络套接字，也可以是其他类型文件，这样的话，该方法既可以监听网络套接字的新事件，也可以监听其他类型文件的新事件，提高了用户态协议栈对现有应用程序的兼容性，进而降低了将现有应用程序移植到用户态协议栈上的难度。101.下面对本发明提供的阻塞式事件通知装置进行描述，下文描述的阻塞式事件通知装置与上文描述的阻塞式事件通知方法可相互对应参照。102.图5示出了本发明实施例提供的阻塞式事件通知装置，该装置包括：103.第一处理模块510，用于根据应用程序发起的第一接口调用请求，向接口兴趣队列中添加待监听文件，并将为网络套接字的待监听文件添加至用户态协议栈的监听队列中；104.第二处理模块520，用于根据应用程序发起的第二接口调用请求，判断接口兴趣队列中是否有网络套接字，在接口兴趣队列中有网络套接字，且用户态协议栈的监听队列中待监听文件无待通知事件时，创建先入先出队列；其中，先入先出队列中无待通知事件；105.第三处理模块530，用于对先入先出队列进行监听，根据监听结果，使应用程序进入阻塞状态或唤醒状态；106.通知模块540，在应用程序进入唤醒状态时，向应用程序发送待通知事件。107.在示例性实施例中，上述第一处理模块510，具体还可以用于：将为非网络套接字的待监听文件添加至内核的监听队列中。108.在示例性实施例中，上述第三处理模块530具体可以用于：通过内核态接口监听先入先出队列；若先入先出队列无待通知事件，则通过内核态接口使应用程序进入阻塞状态；若用户态协议栈的监听队列中待监听文件有待通知事件，则改变先入先出队列的当前状态，以向操作系统内核发出结束阻塞指令；操作系统内核用于通过内核态接口接收结束阻塞指令，根据结束阻塞指令使应用程序结束阻塞并进入唤醒状态。109.更优地，本实施例提供的阻塞式事件通知装置，还可以包括：110.第四处理模块，用于根据应用程序发起的第二接口调用请求，判断接口兴趣队列中是否有网络套接字，在接口兴趣队列中无网络套接字，且内核的监听队列中待监听文件无待通知事件时，通过内核态接口使应用程序进入阻塞状态。111.进一步地，上述第四处理模块还用于：在内核的监听队列中待监听文件有待通知事件时，通过内核态接口唤醒应用程序；向应用程序发送待通知事件。112.需要说明的是，本实施例中第一接口调用请求为对第一用户态接口的调用请求，第一用户态接口可以是用户态事件聚合通知控制接口；113.第二接口调用请求为对第二用户态接口的调用请求，第二用户态接口可以是用户态事件聚合通知等待接口，内核态接口可以是内核态事件聚合通知等待接口。114.由此可见，本实施例提供的阻塞式事件通知装置，当应用程序调用用户态事件聚合通知等待接口监听文件事件时，首先需要判断这个文件是否为网络套接字，如果不是网络套接字，则调用内核态事件聚合通知等待接口来监听该套接字。如果是网络套接字，则借助先入先出队列和内核态事件聚合通知等待接口来监听网络套接字。从而可以获取网络套接字、先入先出队列等多种类型文件的新事件，并支持阻塞式语义，实现了用户态阻塞式事件的聚合通知功能。115.图6示例了一种电子设备的实体结构示意图，如图6所示，该电子设备可以包括：处理器(processor)610、通信接口(communicationsinterface)620、存储器(memory)630和通信总线640，其中，处理器610，通信接口620，存储器630通过通信总线640完成相互间的通信。处理器610可以调用存储器630中的逻辑指令，以执行阻塞式事件通知方法，该方法包括：根据应用程序发起的第一接口调用请求，向接口兴趣队列中添加待监听文件，并将为网络套接字的待监听文件添加至用户态协议栈的监听队列中；根据应用程序发起的第二接口调用请求，判断接口兴趣队列中是否有网络套接字，在接口兴趣队列中有网络套接字，且用户态协议栈的监听队列中待监听文件无待通知事件时，创建先入先出队列；其中，先入先出队列中无待通知事件；对先入先出队列进行监听，根据监听结果，使应用程序进入阻塞状态或唤醒状态；在应用程序进入唤醒状态时，向应用程序发送待通知事件。116.此外，上述的存储器630中的逻辑指令可以通过软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。117.另一方面，本发明还提供一种计算机程序产品，所述计算机程序产品包括计算机程序，计算机程序可存储在非暂态计算机可读存储介质上，所述计算机程序被处理器执行时，计算机能够执行上述各方法所提供的阻塞式事件通知方法，该方法包括：根据应用程序发起的第一接口调用请求，向接口兴趣队列中添加待监听文件，并将为网络套接字的待监听文件添加至用户态协议栈的监听队列中；根据应用程序发起的第二接口调用请求，判断接口兴趣队列中是否有网络套接字，在接口兴趣队列中有网络套接字，且用户态协议栈的监听队列中待监听文件无待通知事件时，创建先入先出队列；其中，先入先出队列中无待通知事件；对先入先出队列进行监听，根据监听结果，使应用程序进入阻塞状态或唤醒状态；在应用程序进入唤醒状态时，向应用程序发送待通知事件。118.又一方面，本发明还提供一种非暂态计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现以执行上述各方法提供的阻塞式事件通知方法，该方法包括：根据应用程序发起的第一接口调用请求，向接口兴趣队列中添加待监听文件，并将为网络套接字的待监听文件添加至用户态协议栈的监听队列中；根据应用程序发起的第二接口调用请求，判断接口兴趣队列中是否有网络套接字，在接口兴趣队列中有网络套接字，且用户态协议栈的监听队列中待监听文件无待通知事件时，创建先入先出队列；其中，先入先出队列中无待通知事件；对先入先出队列进行监听，根据监听结果，使应用程序进入阻塞状态或唤醒状态；在应用程序进入唤醒状态时，向应用程序发送待通知事件。119.以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。120.通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如rom/ram、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。121.最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。当前第1页12当前第1页12
技术领域：
：，尤其涉及一种阻塞式事件通知方法及装置。
背景技术：
：：2.数据中心服务器运行的传统网络应用主要通过linux内核来监听并获取新事件，为了对linux内核的协议栈进行优化，基于高性能数据包收发框架开发的用户态协议栈应运而生。3.然而，对于用户态协议栈来说，由于用户态协议栈和应用程序同时运行在用户态，用户态协议栈没有权限阻塞或唤醒应用程序，导致用户态协议栈提供的用户态事件聚合通知等待接口无法支持阻塞式语义。技术实现要素：4.本发明提供一种阻塞式事件通知方法及装置，用以解决现有技术中用户态事件聚合通知等待接口无法支持阻塞式语义的缺陷。5.第一方面，本发明提供一种阻塞式事件通知方法，该方法包括：6.根据应用程序发起的第一接口调用请求，向接口兴趣队列中添加待监听文件，并将为网络套接字的待监听文件添加至用户态协议栈的监听队列中；7.根据应用程序发起的第二接口调用请求，判断所述接口兴趣队列中是否有网络套接字，在所述接口兴趣队列中有网络套接字，且所述用户态协议栈的监听队列中待监听文件无待通知事件时，创建先入先出队列；其中，所述先入先出队列中无待通知事件；8.对所述先入先出队列进行监听，根据监听结果，使应用程序进入阻塞状态或唤醒状态；9.在应用程序进入唤醒状态时，向应用程序发送待通知事件。10.根据本发明提供的阻塞式事件通知方法，对所述先入先出队列进行监听，根据监听结果，使应用程序进入阻塞状态或唤醒状态，包括：11.通过内核态接口监听所述先入先出队列；12.若所述先入先出队列无待通知事件，则通过所述内核态接口使应用程序进入阻塞状态；13.若所述用户态协议栈的监听队列中所述待监听文件有待通知事件，则改变所述先入先出队列的当前状态，以向操作系统内核发出结束阻塞指令；14.所述操作系统内核用于通过所述内核态接口接收所述结束阻塞指令，根据所述结束阻塞指令使应用程序结束阻塞并进入唤醒状态。15.根据本发明提供的阻塞式事件通知方法，向接口兴趣队列中添加待监听文件之后，还包括：16.将为非网络套接字的待监听文件添加至内核的监听队列中。17.根据本发明提供的阻塞式事件通知方法，还包括：18.根据应用程序发起的第二接口调用请求，判断所述接口兴趣队列中是否有网络套接字，在所述接口兴趣队列中无网络套接字，且所述内核的监听队列中所述待监听文件无待通知事件时，通过内核态接口使应用程序进入阻塞状态。19.根据本发明提供的阻塞式事件通知方法，在所述接口兴趣队列中无网络套接字，且所述内核的监听队列中所述待监听文件无待通知事件时，通过内核态接口使应用程序进入阻塞状态之后，还包括：20.若所述内核的监听队列中所述待监听文件有待通知事件，则通过所述内核态接口唤醒应用程序；21.向应用程序发送所述待通知事件。22.根据本发明提供的阻塞式事件通知方法，所述内核态接口为内核态事件聚合通知等待接口。23.根据本发明提供的阻塞式事件通知方法，所述第一接口调用请求为对第一用户态接口的调用请求，所述第一用户态接口为用户态事件聚合通知控制接口；24.所述第二接口调用请求为对第二用户态接口的调用请求，所述第二用户态接口为用户态事件聚合通知等待接口。25.第二方面，本发明还提供一种阻塞式事件通知装置，该装置包括：26.第一处理模块，用于根据应用程序发起的第一接口调用请求，向接口兴趣队列中添加待监听文件，并将为网络套接字的待监听文件添加至用户态协议栈的监听队列中；27.第二处理模块，用于根据应用程序发起的第二接口调用请求，判断所述接口兴趣队列中是否有网络套接字，在所述接口兴趣队列中有网络套接字，且所述用户态协议栈的监听队列中待监听文件无待通知事件时，创建先入先出队列；其中，所述先入先出队列中无待通知事件；28.第三处理模块，用于对所述先入先出队列进行监听，根据监听结果，使应用程序进入阻塞状态或唤醒状态；29.通知模块，在应用程序进入唤醒状态时，向应用程序发送待通知事件。30.第三方面，本发明还提供一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现如上述任一种所述阻塞式事件通知方法的步骤。31.第四方面，本发明还提供一种非暂态计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现如上述任一种所述阻塞式事件通知方法的步骤。32.本发明提供的阻塞式事件通知方法及装置，通过向接口兴趣队列中添加待监听文件，并确定待监听文件的监听队列，在接口兴趣队列中有网络套接字，且用户态协议栈的监听队列中待监听文件无待通知事件时，创建先入先出队列，对先入先出队列进行监听，根据监听结果，使应用程序进入阻塞状态或唤醒状态，从而使用户态事件聚合通知等待接口能够支持阻塞式语义，提高了用户态协议栈对现有应用程序的兼容性。附图说明33.为了更清楚地说明本发明或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。34.图1是本发明提供的阻塞式事件通知方法的流程示意图之一；35.图2是本发明提供的阻塞式事件通知方法的流程示意图之二；36.图3是本发明提供的阻塞式事件通知方法的流程示意图之三；37.图4是本发明提供的阻塞式事件通知方法的流程示意图之四；38.图5是本发明提供的阻塞式事件通知装置的结构示意图；39.图6是本发明提供的电子设备的结构示意图。具体实施方式40.为使本发明的目的、技术方案和优点更加清楚，下面将结合本发明中的附图，对本发明中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。41.首先对本发明针对的技术背景和现有的事件通知方法存在的不足进行详细说明。42.数据中心服务器运行的传统网络应用，主要通过linux内核来监听并获取新事件，linux内核主要存在以下两大问题：43.第一，对用户来说，随着高速网卡和多核cpu的不断发展，linux内核的网络协议栈成为主要的性能瓶颈，无法满足当前网络应用的高性能网络流量处理需求；44.第二，对开发者来说，由于牵涉到操作系统内核，新功能调试难，开发周期长。因此，自从linux诞生之日起，对于内核的改进就一直在进行。45.针对linux内核进行优化的方案中，高性能数据包收发(input/output，i/o)框架，如inteldpdk、netmap等，虽然极大提高了数据收发性能，但是这些高性能数据包i/o框架本身并没有提供完整的事件聚合通知机制，阻碍了其在业界的广泛使用。46.基于高性能数据包i/o框架开发的用户态协议栈，例如mtcp、ix等，虽然具有较高的性能，但是其提供的应用程序接口(applicationprogramminginterface，api)与可移植操作系统接口(portableoperatingsysteminterfaceforunix，posixapi)的语义和功能不同，不能完全兼容现有应用程序。47.操作系统内核提供的内核态事件聚合通知等待接口是高性能网络应用常用的api之一，应用程序通过调用该接口，可以监听网络套接字(socket)、先入先出队列(firstinfirstout,fifo)等多种类型文件的新事件。当无新事件时，操作系统内核可以让应用程序进入阻塞状态，节约cpu资源。当新事件到来时，操作系统内核可以唤醒应用程序读取新事件。48.然而，对于用户态协议栈来说，由于用户态协议栈和应用程序同时运行在用户态，用户态协议栈没有权限阻塞或唤醒应用程序，导致用户态协议栈提供的用户态事件聚合通知等待接口无法支持阻塞式语义。49.另外，由于现有用户态协议栈主要负责网络数据的收发，其提供的用户态事件聚合通知等待接口仅支持监听网络套接字的新事件而不支持监听其他类型文件的新事件。50.这些不足限制了用户态协议栈对现有应用程序的兼容性，提高了将现有应用程序移植到用户态协议栈上的难度。51.为此，本发明对现有的用户态阻塞式事件通知方法进行改进，下面结合图1-图6描述本发明实施例提供的阻塞式事件通知方法及装置，以及应用该方法的电子设备。52.图1示出了本发明实施例提供的阻塞式事件通知方法，该方法包括：53.步骤110：根据应用程序发起的第一接口调用请求，向接口兴趣队列中添加待监听文件，并将为网络套接字的待监听文件添加至用户态协议栈的监听队列中。54.更优地，向接口兴趣队列中添加待监听文件之后，还可以包括：55.将为非网络套接字的待监听文件添加至内核的监听队列中。56.在示例性实施例中，参见附图2，向接口兴趣队列中添加待监听文件，并确定待监听文件的监听队列的过程，具体可以包括：57.步骤210：若应用程序调用第一用户态接口；58.步骤220：将待监听文件的文件描述符添加至接口兴趣队列中；59.步骤230：判断待监听文件是否为网络套接字(socket)；60.步骤240：若是，则将待监听文件的文件描述符添加至用户态协议栈的监听队列中；61.步骤250：若否，则将待监听文件的文件描述符添加至内核的监听队列中。62.需要说明的是，本实施例中第一接口调用请求为对第一用户态接口的调用请求，第一用户态接口可以是用户态(阻塞式)事件聚合通知控制接口epoll_ctl()，应用程序调用该接口时，可以发起添加待监听文件的请求，进而可以将待监听文件的文件描述符添加至epoll兴趣队列(即接口兴趣队列)中。63.本实施例可以添加多个待监听文件，进而可以同时监听多个感兴趣文件，从而后续能够实现阻塞式事件的聚合通知。64.可以理解的是，本实施例中待监听文件可以是用于传输数据的网络文件，此时该待监听文件的事件可以是读事件或者写事件。65.步骤120：根据应用程序发起的第二接口调用请求，判断接口兴趣队列中是否有网络套接字，在接口兴趣队列中有网络套接字，且用户态协议栈的监听队列中待监听文件无待通知事件时，创建先入先出队列；其中，先入先出队列中无待通知事件。66.需要说明的是，本实施例中第二接口调用请求为对第二用户态接口的调用请求，第二用户态接口可以是用户态(阻塞式)事件聚合通知等待接口epoll_wait()。67.步骤130：对先入先出队列进行监听，根据监听结果，使应用程序进入阻塞状态或唤醒状态。68.在示例性实施例中，对先入先出队列进行监听，根据监听结果，使应用程序进入阻塞状态或唤醒状态的过程，具体可以包括：69.通过内核态接口监听先入先出队列；70.若先入先出队列无待通知事件，则通过内核态接口使应用程序进入阻塞状态；71.若用户态协议栈的监听队列中待监听文件有待通知事件，则改变先入先出队列的当前状态，以向操作系统内核发出结束阻塞指令；72.操作系统内核用于通过内核态接口接收结束阻塞指令，根据结束阻塞指令使应用程序结束阻塞并进入唤醒状态。73.考虑到实际应用过程中，只有操作系统内核才能直接使应用程序进入阻塞或唤醒状态，本实施例中用户态协议栈通过调用内核态接口，可以间接地使应用程序进入阻塞或唤醒状态，进而使得用户态协议栈提供的用户态事件聚合通知等待接口可以支持阻塞式语义。74.步骤140：在应用程序进入唤醒状态时，向应用程序发送待通知事件。75.更优地，本实施例提供的阻塞式事件通知方法，还可以包括：76.根据应用程序发起的第二接口调用请求，判断接口兴趣队列中是否有网络套接字，在接口兴趣队列中无网络套接字，且内核的监听队列中待监听文件无待通知事件时，通过内核态接口使应用程序进入阻塞状态。77.进一步地，在接口兴趣队列中无网络套接字，且内核的监听队列中待监听文件无待通知事件时，通过内核态接口使应用程序进入阻塞状态之后，还可以包括：78.若内核的监听队列中待监听文件有待通知事件，则通过内核态接口唤醒应用程序；79.向应用程序发送待通知事件。80.需要说明的是，本实施例中内核态接口可以是内核态(阻塞式)事件聚合通知等待接口kernel_epoll_wait()。81.本实施例针对的第一用户态接口、第二用户态接口以及内核态接口均指的是阻塞式接口，是指在未监听到感兴趣文件的新事件时,即没有需要向应用程序通知的事件时，就使应用程序进入阻塞状态,等待新事件的到来。而对于非阻塞式接口，则没有上述等待环节。82.参见附图3，在应用程序调用用户态事件聚合通知等待接口epoll_wait()时，本实施例提供的阻塞式事件通知方法，具体执行以下流程：83.步骤310：在应用程序调用第二用户态接口时，即调用用户态事件聚合通知等待接口epoll_wait()；84.步骤320：判断epoll兴趣队列(即接口兴趣队列)中是否有网络套接字；85.步骤330：若epoll兴趣队列中有网络套接字，则判断用户态协议栈的监听队列中待监听文件是否已有新事件(即待通知事件)；86.若有新事件，则执行步骤390；87.若没有新事件，则执行步骤340：创建fifo(firstinputfirstoutput，先入先出队列)；88.步骤350：调用内核态事件聚合通知等待接口kernel_epoll_wait()监听先入先出队列，此时先入先出队列中无新事件；89.步骤360：内核态事件聚合通知等待接口kernel_epoll_wait()使应用程序进入阻塞状态，以等待新事件；90.步骤370：若epoll兴趣队列中没有网络套接字，则调用内核态事件聚合通知等待接口kernel_epoll_wait()；91.步骤380：判断内核的监听队列中的待监听文件是否已有新事件(即待通知事件)，若有新事件，则执行步骤390；若没有新事件，则执行步骤360；92.步骤390：返回新事件给应用程序，事件通知流程结束。93.参见附图4，当新事件到来时，本实施例提供的阻塞式事件通知方法，具体执行以下流程：94.步骤410：当内核的监听队列中的待监听文件有新事件(即待通知事件)时，依次执行步骤440和步骤450；95.步骤420：当用户态协议栈的监听队列中待监听文件有新事件时，依次执行步骤430、步骤440和步骤450；96.步骤430：改变先入先出队列的当前状态，具体可以通过用户态协议栈将任意字符写入先入先出队列中，比如用户态协议栈可以通过将“1”写入先入先出队列中以产生一个新事件；97.步骤440：通过内核态事件聚合通知等待接口kernel_epoll_wait()结束阻塞，使操作系统内核唤醒应用程序；98.步骤450：通过用户态事件聚合通知等待接口epoll_wait()将新事件返回给应用程序。99.这样的话，通过创建先入先出队列，利用先入先出队列与内核态事件聚合通知等待接口配合，能够实现对应用程序阻塞状态和唤醒状态的控制，可以解决传统事件通知过程中，用户态协议栈没有权限阻塞或唤醒应用程序，导致用户态协议栈提供的用户态事件聚合通知等待接口无法支持阻塞式语义的问题。100.同时，本实施例提供的方法中待监听文件既可以是网络套接字，也可以是其他类型文件，这样的话，该方法既可以监听网络套接字的新事件，也可以监听其他类型文件的新事件，提高了用户态协议栈对现有应用程序的兼容性，进而降低了将现有应用程序移植到用户态协议栈上的难度。101.下面对本发明提供的阻塞式事件通知装置进行描述，下文描述的阻塞式事件通知装置与上文描述的阻塞式事件通知方法可相互对应参照。102.图5示出了本发明实施例提供的阻塞式事件通知装置，该装置包括：103.第一处理模块510，用于根据应用程序发起的第一接口调用请求，向接口兴趣队列中添加待监听文件，并将为网络套接字的待监听文件添加至用户态协议栈的监听队列中；104.第二处理模块520，用于根据应用程序发起的第二接口调用请求，判断接口兴趣队列中是否有网络套接字，在接口兴趣队列中有网络套接字，且用户态协议栈的监听队列中待监听文件无待通知事件时，创建先入先出队列；其中，先入先出队列中无待通知事件；105.第三处理模块530，用于对先入先出队列进行监听，根据监听结果，使应用程序进入阻塞状态或唤醒状态；106.通知模块540，在应用程序进入唤醒状态时，向应用程序发送待通知事件。107.在示例性实施例中，上述第一处理模块510，具体还可以用于：将为非网络套接字的待监听文件添加至内核的监听队列中。108.在示例性实施例中，上述第三处理模块530具体可以用于：通过内核态接口监听先入先出队列；若先入先出队列无待通知事件，则通过内核态接口使应用程序进入阻塞状态；若用户态协议栈的监听队列中待监听文件有待通知事件，则改变先入先出队列的当前状态，以向操作系统内核发出结束阻塞指令；操作系统内核用于通过内核态接口接收结束阻塞指令，根据结束阻塞指令使应用程序结束阻塞并进入唤醒状态。109.更优地，本实施例提供的阻塞式事件通知装置，还可以包括：110.第四处理模块，用于根据应用程序发起的第二接口调用请求，判断接口兴趣队列中是否有网络套接字，在接口兴趣队列中无网络套接字，且内核的监听队列中待监听文件无待通知事件时，通过内核态接口使应用程序进入阻塞状态。111.进一步地，上述第四处理模块还用于：在内核的监听队列中待监听文件有待通知事件时，通过内核态接口唤醒应用程序；向应用程序发送待通知事件。112.需要说明的是，本实施例中第一接口调用请求为对第一用户态接口的调用请求，第一用户态接口可以是用户态事件聚合通知控制接口；113.第二接口调用请求为对第二用户态接口的调用请求，第二用户态接口可以是用户态事件聚合通知等待接口，内核态接口可以是内核态事件聚合通知等待接口。114.由此可见，本实施例提供的阻塞式事件通知装置，当应用程序调用用户态事件聚合通知等待接口监听文件事件时，首先需要判断这个文件是否为网络套接字，如果不是网络套接字，则调用内核态事件聚合通知等待接口来监听该套接字。如果是网络套接字，则借助先入先出队列和内核态事件聚合通知等待接口来监听网络套接字。从而可以获取网络套接字、先入先出队列等多种类型文件的新事件，并支持阻塞式语义，实现了用户态阻塞式事件的聚合通知功能。115.图6示例了一种电子设备的实体结构示意图，如图6所示，该电子设备可以包括：处理器(processor)610、通信接口(communicationsinterface)620、存储器(memory)630和通信总线640，其中，处理器610，通信接口620，存储器630通过通信总线640完成相互间的通信。处理器610可以调用存储器630中的逻辑指令，以执行阻塞式事件通知方法，该方法包括：根据应用程序发起的第一接口调用请求，向接口兴趣队列中添加待监听文件，并将为网络套接字的待监听文件添加至用户态协议栈的监听队列中；根据应用程序发起的第二接口调用请求，判断接口兴趣队列中是否有网络套接字，在接口兴趣队列中有网络套接字，且用户态协议栈的监听队列中待监听文件无待通知事件时，创建先入先出队列；其中，先入先出队列中无待通知事件；对先入先出队列进行监听，根据监听结果，使应用程序进入阻塞状态或唤醒状态；在应用程序进入唤醒状态时，向应用程序发送待通知事件。116.此外，上述的存储器630中的逻辑指令可以通过软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。117.另一方面，本发明还提供一种计算机程序产品，所述计算机程序产品包括计算机程序，计算机程序可存储在非暂态计算机可读存储介质上，所述计算机程序被处理器执行时，计算机能够执行上述各方法所提供的阻塞式事件通知方法，该方法包括：根据应用程序发起的第一接口调用请求，向接口兴趣队列中添加待监听文件，并将为网络套接字的待监听文件添加至用户态协议栈的监听队列中；根据应用程序发起的第二接口调用请求，判断接口兴趣队列中是否有网络套接字，在接口兴趣队列中有网络套接字，且用户态协议栈的监听队列中待监听文件无待通知事件时，创建先入先出队列；其中，先入先出队列中无待通知事件；对先入先出队列进行监听，根据监听结果，使应用程序进入阻塞状态或唤醒状态；在应用程序进入唤醒状态时，向应用程序发送待通知事件。118.又一方面，本发明还提供一种非暂态计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现以执行上述各方法提供的阻塞式事件通知方法，该方法包括：根据应用程序发起的第一接口调用请求，向接口兴趣队列中添加待监听文件，并将为网络套接字的待监听文件添加至用户态协议栈的监听队列中；根据应用程序发起的第二接口调用请求，判断接口兴趣队列中是否有网络套接字，在接口兴趣队列中有网络套接字，且用户态协议栈的监听队列中待监听文件无待通知事件时，创建先入先出队列；其中，先入先出队列中无待通知事件；对先入先出队列进行监听，根据监听结果，使应用程序进入阻塞状态或唤醒状态；在应用程序进入唤醒状态时，向应用程序发送待通知事件。119.以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。120.通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如rom/ram、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。121.最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。当前第1页12当前第1页12
再多了解一些
本文用于企业家、创业者技术爱好者查询，结果仅供参考。
