io selectԴ??

       不是手表，epoll是源码Linux内核为处理大批量文件描述符而作了改进的poll，是源码Linux下多路复用IO接口select/poll的增强版本，它能显著提高程序在大量并发连接中只有少量活跃的源码情况下的系统CPU利用率。

       epoll和select区别总结？

       epoll是源码Linux内核为处理大批量文件描述符而作了改进的poll，是源码jvm实战源码Linux下多路复用IO接口select/poll的增强版本，它能显著提高程序在大量并发连接中只有少量活跃的源码情况下的系统CPU利用率。

       elect是源码一个计算机函数，位于头文件#include。源码该函数用于监视文件描述符的源码变化情况——读写或是异常。

       fd文件夹是源码什么意思？

       fd，即filedescriptor，源码文件描述符。源码linux下，源码所有的源码操作都是对文件进行操作，而对文件的操作是利用文件描述符(filedescriptor)来实现的。

       每个文件进程控制块中都有一份文件描述符表（可以把它看成是一个数组，里面的元素是指向file结构体指针类型），这个数组的下标就是文件描述符。在源代码中，一般用fd作为文件描述符的标识。

       linux什么数据结构存放进程打开的文件信息？

       linux系统下查看进程打开文件在/proc下，对应每个进程有一个以进程号命名的regex谷歌源码目录，该目录下有一个fd目录，该目录下面的每个文件是一个符号连接，其文件名对应该进程占用的一个文件描述符，而连接指向的内容表示文件描述符对应的实际文件，有多少个文件描述符表示该进程打开了多少文件。

       另外Linux默认的进程打开文件上限是个，可以通过ulimit-n查看。很多系统上限可以通过修改/etc/security/limits.conf文件改变，这个文件有详细的注释，对如何修改做了说明。

       如果希望把所有用户的进程打开文件上限改为，可以加入下面两行*softnofile*hardnofile还可以只真对某个用户或某个组做修改，具体方法参见文件注释。修改后需要重新启动系统才能生效。

       linux如何设置进程所能打开的最大文件描述符个数？

       每个进程的文件描述符都是唯一的;文件描述符是file_struct结构中的file(打开文件创建的对象)指针数组的索引,file对象只有打开文件时才会创建并与文件描述符相关联fd_install(fd,f)

       ;进程间传递文件描述符除了父子进程外,没啥意义.父子进程之间会将file_struct的file指针数组全部拷贝,所以子进程才可以用父进程fd.

如何理解 Tornado

       å‡è®¾ä½ è¿˜ä¸çŸ¥é“Tornado是什么也不知道为什么应该对它感兴趣，那我将用简短的话来介绍Tornado这个项目。如果你已经对它有了兴趣，你可以跳去看下一节内容。

       Tornado是一个用Python编写的异步HTTP服务器，同时也是一个web开发框架。该框架服务于FriendFeed网站，最近Facebook也在使用它。FriendFeed网站有用户数多和应用实时性强的特点，所以性能和可扩展性是很受重视的。由于现在它是开源的了（这得归功于Facebook），我们可以彻底的对它是如何工作的一探究竟。

       æˆ‘觉得对非阻塞式IO (nonblocking IO) 和异步IO (asynchronous IO AIO)很有必要谈一谈。如果你已经完全知道他们是什么了，可以跳去看下一节。我尽可能的使用一些例子来说明它们是什么。

       è®©æˆ‘们假设你正在写一个需要请求一些来自其他服务器上的数据（比如数据库服务，再比如新浪微博的open api）的应用程序，然后呢这些请求将花费一个比较长的时间，假设需要花费5秒钟。大多数的web开发框架中处理请求的代码大概长这样：

       def handler_request(self, request):

        answ = self.remote_server.query(request) # this takes 5 seconds

        request.write_response(answ)

       å¦‚果这些代码运行在单个线程中，你的服务器只能每5秒接收一个客户端的请求。在这5秒钟的时间里，服务器不能干其他任何事情，所以，你的服务效率是每秒0.2个请求，哦，这太糟糕了。

       å½“然，没人那么天真，大部分服务器会使用多线程技术来让服务器一次接收多个客户端的请求，我们假设你有个线程，你将在性能上获得倍的提高，所以现在你的服务器效率是每秒接受4个请求，但这还是太低了，当然，你可以通过不断地提高线程的数量来解决这个问题，但是，线程在内存和调度方面的开销是昂贵的，我怀疑如果你使用这种提高线程数量的方式将永远不可能达到每秒个请求的效率。

       å¦‚果使用AIO，达到每秒上千个请求的效率是非常轻松的事情。服务器请求处理的代码将被改成这样：

       def handler_request(self, request):

        self.remote_server.query_async(request, self.response_received)

       def response_received(self, request, answ): # this is called 5 seconds later

        request.write(answ)

       AIO的思想是当我们在等待结果的时候不阻塞，转而我们给框架一个回调函数作为参数，让框架在有结果的时候通过回调函数通知我们。这样，服务器就可以被解放去接受其他客户端的请求了。

       ç„¶è€Œè¿™ä¹Ÿæ˜¯AIO不太好的地方：代码有点不直观了。还有，如果你使用像Tornado这样的单线程AIO服务器软件，你需要时刻小心不要去阻塞什么，因为所有本该在当前返回的请求都会像上述处理那样被延迟返回。

       å…³äºŽå¼‚æ­¥IO，比当前这篇过分简单的介绍更好的学习资料请看 The CK problem。

       æºä»£ç 

       è¯¥é¡¹ç›®ç”±github托管，你可以通过如下命令获得，虽然通过阅读这篇文章你也可以不需要它是吧。

       git clone git://github.com/facebook/tornado.git

       åœ¨tornado的子目录中，每个模块都应该有一个.py文件，你可以通过检查他们来判断你是否从已经从代码仓库中完整的迁出了项目。在每个源代码的文件中，你都可以发现至少一个大段落的用来解释该模块的doc string，doc string中给出了一到两个关于如何使用该模块的例子。

       IOLoop模块

       è®©æˆ‘们通过查看ioloop.py文件直接进入服务器的核心。这个模块是异步机制的核心。它包含了一系列已经打开的文件描述符（译者：也就是文件指针）和每个描述符的处理器（handlers）。它的功能是选择那些已经准备好读写的文件描述符，然后调用它们各自的处理器（一种IO多路复用的实现，其实就是socket众多IO模型中的select模型，在Java中就是NIO，译者注）。

       å¯ä»¥é€šè¿‡è°ƒç”¨add_handler()方法将一个socket加入IO循环中：

       def add_handler(self, fd, handler, events):

        """Registers the given handler to receive the given events for fd."""

        self._handlers[fd] = handler

        self._impl.register(fd, events | self.ERROR)

       _handlers这个字典类型的变量保存着文件描述符（其实就是socket，译者注）到当该文件描述符准备好时需要调用的方法的映射（在Tornado中，该方法被称为处理器）。然后，文件描述符被注册到epoll（unix中的一种IO轮询机制，貌似，译者注）列表中。Tornado关心三种类型的事件（指发生在文件描述上的事件，译者注）：READ，WRITE 和 ERROR。正如你所见，ERROR是默认为你自动添加的。

       self._impl是select.epoll()和selet.select()两者中的一个。我们稍后将看到Tornado是如何在它们之间进行选择的。

       çŽ°åœ¨è®©æˆ‘们来看看实际的主循环，不知何故，这段代码被放在了start()方法中：

       def start(self):

        """Starts the I/O loop.

        The loop will run until one of the I/O handlers calls stop(), which

        will make the loop stop after the current event iteration completes.

        """

        self._running = True

        while True:

        [ ... ]

        if not self._running:

        break

        [ ... ]

        try:

        event_pairs = self._impl.poll(poll_timeout)

        except Exception, e:

        if e.args == (4, "Interrupted system call"):

        logging.warning("Interrupted system call", exc_info=1)

        continue

        else:

        raise

        # Pop one fd at a time from the set of pending fds and run

        # its handler. Since that handler may perform actions on

        # other file descriptors, there may be reentrant calls to

        # this IOLoop that update self._events

        self._events.update(event_pairs)

        while self._events:

        fd, events = self._events.popitem()

        try:

        self._handlers[fd](fd, events)

        except KeyboardInterrupt:

        raise

        except OSError, e:

        if e[0] == errno.EPIPE:

        # Happens when the client closes the connection

        pass

        else:

        logging.error("Exception in I/O handler for fd %d",

        fd, exc_info=True)

        except:

        logging.error("Exception in I/O handler for fd %d",

        fd, exc_info=True)

       poll()方法返回一个形如(fd: events)的键值对，并赋值给event_pairs变量。由于当一个信号在任何一个事件发生前到来时，C函数库中的poll()方法会返回EINTR（实际是一个值为4的数值），所以"Interrupted system call"这个特殊的异常需要被捕获。更详细的请查看man poll。

       åœ¨å†…部的while循环中，event_pairs中的内容被一个一个的取出，然后相应的处理器会被调用。pipe 异常在这里默认不进行处理。为了让这个类适应更一般的情况，在http处理器中处理这个异常是一个更好的方案，但是选择现在这样处理或许是因为更容易一些。

       æ³¨é‡Šä¸­è§£é‡Šäº†ä¸ºä»€ä¹ˆä½¿ç”¨å­—典的popitem()方法，而不是使用更普遍一点的下面这种做法（指使用迭代，译者注）：

       for fd, events in self._events.items():

       åŽŸå› å¾ˆç®€å•ï¼Œåœ¨ä¸»å¾ªçŽ¯æœŸé—´ï¼Œè¿™ä¸ª_events字典变量可能会被处理器所修改。比如remove_handler()处理器。这个方法把fd（即文件描述符，译者注）从_events字典中取出（extracts，意思是取出并从_events中删除，译者注），所以即使fd被选择到了，它的处理器也不会被调用（作者的意思是，如果使用for迭代循环_events，那么在迭代期间_events就不能被修改，否则会产生不可预计的错误，比如，明明调用了remove_handler()方法删除了某个<fd, handler>键值对，但是该handler还是被调用了，译者注）。

每日开源：一个巨硬的产品级嵌入式流媒体库

       哈喽，我是老吴。

       今天分享一个比较复杂的开源项目：live 是一个开源的流媒体库，用于实现实时流媒体的传输和处理。它提供了一套跨平台的 C++ 类库，帮助快速构建高效、可靠的流媒体服务器和客户端应用程序。

       live的irrlicht源码下载代码量庞大，约9w行代码。如果专注于核心逻辑，代码量缩减到约8K行。使用live，你可以收获高效可靠的流媒体库，了解产品级的C++项目设计，掌握音视频基础知识，甚至获得基于select()的C++事件循环库。live在媒体播放器、流媒体服务器、视频监控系统等领域应用广泛，如VLC、FFmpeg、GStreamer均使用live实现流媒体的接收和播放。

       live基于C++，语法相对简单，适合专注于学习C++类设计和编写专业的C++软件。为了理解源码，需要补充多媒体、流媒体的理论知识。通过阅读和运行相关应用，加深对理论知识的米家源码理解。

       编译live库后，会生成4个静态库：libBasicUsageEnvironment.a和libUsageEnvironment.a用于实现事件循环、上下文管理、任务管理等；libliveMedia.a负责多媒体流化，包括音视频编解码、流媒体协议实现；libgroupsock.a负责网络IO功能，核心是TCP、UDP的读写。简单示例是RTP传输MP3音频，涉及server和client两个程序。

       server程序的核心逻辑包括准备运行环境、设置数据来源、设置数据目的地。TaskScheduler用于任务管理，基于select()实现事件循环。BasicUsageEnvironment用于上下文管理。数据流化本质是网络传输，Source和Sink分别表示数据源和目的地，本例中Source是MP3FileSource，Sink是MPEG1or2AudioRTPSink。client端程序同样初始化Source和Sink。

       RTP协议简介，砍价源码分析RTP（Real-time Transport Protocol）是一种用于实时传输音频和视频数据的网络传输协议，基于UDP，用于在IP网络上传输实时媒体数据。RTP协议设计目标是提供低延迟、高效率的传输，以满足实时应用需求。主要特点包括时间戳、序列号、负载类型、NACK反馈和RTCP（Real-time Transport Control Protocol）等。

       关键问题是如何实现数据一帧帧流化？关注点不是具体音视频格式解析或特定协议实现，而是live对音视频流化的整体框架。通过示例分析，live本质上将音视频数据逐帧解码，通过RTP协议经网络发送。live封装了多种数据Source和Sink，但无需详细了解每个概念。仍以RTP传输MP3数据为例，分析live的工作流程。

       首先，需要对相关类的关系有大概概念：MediaSource是所有Source的父类，各种具体音视频Source基于其派生；MediaSink是所有Sink的父类，派生出FileSink、RTPSink等众多Sink类。Sink类最关键的成员函数是startPlaying()，用于使用Source对象获取帧数据，然后发送至网络。

       RTP传输MP3的主要逻辑包括准备就绪后调用MediaSink::startPlaying()启动数据流化，在packFrame()调用Source对象的getNextFrame()。getNextFrame()最终调用MP3FileSource的doGetNextFrame()，负责MP3音频解码，解码完成后，回调afterGettingFrame()，正常时调用sendPacketIfNecessary()发送数据，并添加至事件循环调度器中。一段时间后，MultiFramedRTPSink的sendNext()被调用，推动新一帧数据传输，直到Source中的所有帧数据被消费。

       live如何创建RTSP服务器？通常RTP协议与RTSP协议结合使用，对外提供RTSP服务器服务。RTSP提供控制实时流媒体传输和播放的标准化方式，可以控制播放、暂停、停止、快进、后退等功能。添加几行代码即可创建RTSP服务器。RTSP服务器封装实现RTSP服务，类似HTTP协议，是文本协议。服务器包括接受客户端连接、读取客户端数据、解析和处理数据的操作。

       总结，live是一个开源的多媒体流媒体库，支持常见流媒体协议，提供高效可靠的流媒体传输功能，适用于构建流媒体服务器和客户端应用程序。使用live需要熟悉C++编程和网络编程知识，官方提供丰富示例代码，帮助快速熟悉库的使用方法。

网络I/O库总结（libevent,libuv,libev,libeio）

       Libevent

       Libevent 是一个基于事件驱动模型的非阻塞网络库，用于构建高速、可移植的非阻塞 IO 应用。广泛应用于 memcached、Vomit、Nylon、Netchat 等项目中，作为底层网络库，用于实现 TCP 或 HTTP 服务。Libevent 的 GitHub 源码可访问。

       Libev

       Libev 是由 Marc Lehmann 独立完成的，对不同系统非阻塞模型进行简单封装，解决了不同 API 之间的不兼容问题，保证程序在大多数 *nix 平台上运行。Libev 支持类 UNIX 系统的多种 I/O 多路复用模型，如 select、poll、epoll、kqueue、evports 等，但对于 Windows 的支持仅限于 select 模型，效率较低，性能不如 Libuv 封装的 IOCP。Libev 目标是修复 Libevent 的一些设计问题，如避免使用全局变量，提供更高效的事件类型管理。

       Libuv

       Libuv 是一个跨平台、高性能、事件驱动的异步 IO 库，用 C 语言编写，封装了不同平台底层的高性能 IO 模型，如 epoll、kqueue、IOCP、event ports，具有高度可移植性。Libuv 为 Node.js 设计，但因其高效模型逐渐被其他语言和项目采纳，用于底层库，如 Luvit、Julia、uvloop、pyuv 等。

       Libevent、Libev、Libuv 比较

       根据 GitHub 星标数，Libuv 的影响力最大，其次是 Libevent，Libev 关注较少。在优先级、事件循环、线程安全等方面，Libuv 更为现代，支持多种平台和 IO 模型，提供了更优的性能和功能。Libevent 和 Libev 分别针对不同平台和需求进行优化，Libev 旨在修复 Libevent 的问题。性能和可移植性方面，Libuv 优于 Libevent 和 Libev。

       异步 IO 实现

       目前 Linux 异步 IO 实现有原生异步 IO 和多线程模拟异步 IO 两种方式。原生异步 IO 支持特定场景，但不充分利用 Page cache；多线程模拟异步 IO 方式如 Glibc AIO、libeio、io_uring 等，提供更广泛的适用场景。