碎碎念念

前言

在嵌入式Linux这块，对设备树一直都没怎么去了解，一直是模模糊糊的。所以最近也是被老大赶鸭子上架，快速跟着正点原子的驱动开发的课程学了一下。感觉对设备树的认识也是更清晰了一点。同样借着此篇博客记录了一下我的理解。起一个备忘的作用也希望能帮到其他人。

正文

其实类比理解的话DTS相当于.c源文件，文件描述板级设备信息。一个平台或机器对应一个.dts源文件。

• DTI相当于c语言的头文件。

• DTC相当于于gcc，可以将dts文件编译生成dtb文件

• DTB相当于二进制.o文件，由DTC将DTS编译生成。

前言

系列链接如下：

WorkFlow源码剖析——GO-Task 源码分析

WorkFlow源码剖析——Communicator之TCPServer（上）

WorkFlow源码剖析——Communicator之TCPServer（中）

WorkFlow源码剖析——Communicator之TCPServer（下）

终于来到TCPServer最后一部分，前面两篇博客已经深入分析了WorkFlow底层poller和Communicator的实现细节，本篇博客将会从整体视角，整合前面所讲的poller以及Communicator形成最终的TCPServer。

同样放上workflow开源项目的Github地址：https://github.com/sogou/workflow

和GO-Task的实现类似，尤其需要注意对基类SubTask、CommSession虚函数的重写。如果你看过GO-Task的实现，本文最终所讲的TCPServer任务其实差不多。因为TCPServer的继承树和GO-Task的继承树不能说相似，只能说一模一样。对称性对框架的设计真的很重要，我认为对称思想（也可以说成抽象思想）是优雅的象征。并且对称性可以帮我们减少出BUG的风险。如果你刷过的LeetCode，你一定会发现，在解答那些对边界条件要求很高的题目时，如果你能给各种情况抽象出一套统一的逻辑说词，大概率就不会wa。

前言

本文简单记录一下我在学习IPCamera项目的的OSD的原理的过程。

在学习OSD的过程当中，可能需要补充的基础知识：

1. OSD是什么？

2. BMP图像文件格式大致组成？

3. 图像调色（Palette）的原理？

4. RGA常用接口的使用？

WorkFlow源码剖析——GO-Task 源码分析

WorkFlow源码剖析——Communicator之TCPServer（上）

WorkFlow源码剖析——Communicator之TCPServer（中）

WorkFlow源码剖析——Communicator之TCPServer（下）

前言

上节博客已经详细介绍了workflow的poller的实现，这节我们来看看Communicator是如何利用poller的，对连接对象生命周期的管理。（PS：与其说Communicator利用的是poller，其实Communicator使用的是mpoller，上节在介绍poller时也提到过mpoller，现场帮读者回忆一下：mpoller是poller的manager类，管理多个poller事件池，对外提供的接口负责将各种poller_node负载均衡的分散给不同的poller。）

上节在介绍poller时，出现了各种回调，比如poller->callback()、node->data.accept()、node->data.partial_written()、node->data.create_message()等，当时我们总是一笔带过，没有去深入分析这些回调会做什么？并且每次在IO事件结束都会回调poller->callback()为什么要这样做？在poller当中，只看到了针对poller_node的malloc函数，而没有看到对应的free函数，哪里调用了free函数去释放poller_node？

WorkFlow源码剖析——GO-Task 源码分析

WorkFlow源码剖析——Communicator之TCPServer（上）

WorkFlow源码剖析——Communicator之TCPServer（中）

WorkFlow源码剖析——Communicator之TCPServer（下）

前言

上一篇博客已经介绍了一下WorkFlow GO-Task的实现原理。本文会介绍一下WorkFlow Tcp Server端的一些实现细节以及有趣的思想。因为这部分涉及的内容有点多，一些有趣的细节也希望能完整的叙述出来，所以我可能会将TCPServer拆分成上中下三个部分。三个部分分别对应：poller的实现（即对IO对路复用事件池的封装，属于最底层），Communicator的实现（对连接对象生命周期的管理，属于中间层），最后就是TCPServer的实现（利用中间层实现一个TCPServer）。文件异步IO相关的内容，后面抽空会补上。

前言

本文的名字应该是我所写过的博客当中最长的，但内容以精简且保证实用为原则！

正文

首先是ffmpeg

环境搭建流程如下：

0. 在网上下载已经被编译成动态库版的ffmpeg，我的是：ffmpeg-N-113099-g46775e64f8-win64-gpl-shared。

adb push src dest

file 可执行文件 获取可执行文件架构

modetest命令可以查看图层信息

RKMedia的各个组件及其交互

首先上图：

WorkFlow GO-Task 源码分析

WorkFlow源码剖析——Communicator之TCPServer（上）

WorkFlow源码剖析——Communicator之TCPServer（中）

WorkFlow源码剖析——Communicator之TCPServer（下）

前言

任何好的框架的设计都是围绕着一个核心思想去展开，sylar的一切皆协程、muduo的one loop per thread等。一切皆是任务流就是workflow的精髓。（PS，目前作者功力尚浅，许多设计细节还未能悟透其用意，目前也只能尽力将我的理解呈现出来，有错误非常欢迎指出。

也是尝试着阅读过许多开源优秀的代码，这里记录一下我个人在阅读一份源码时的习惯：适可而止的自低向上。因为我在阅读一份完全不了解的源码时，迫不及待的想去知道每个每个模块、每个函数的实现细节，我也曾尝试以自顶向下去阅读一份源码，但是无法克制自己钻牛角尖的心，并且在经验尚浅，完全不了解设计背景的境况下，自顶向下去阅读一份源码，某一个函数的实现你只能去猜，由于经验尚浅，你大概率猜的也是错误的。所以，兜兜转转，我还是遵循我个人的习惯，自低向上去阅读一份源码。当然，应该：适可而止的自低向上，一些你完全知道起什么作用的模块其实就不必去深究了，比如：链表、红黑树、编码器等。深入细节的同时，也不要忘了我们的初心：框架的设计思想。

最近也是在研究workflow框架的源码，看到里面的线程池也用到了线程局部变量，但是用法和sylar的不同，特此来简单记录一下。

场景分析

在实际开发中，存在这样一种需求：需要让每一个线程用拥有自己的“独有”的全局变量，听着视乎有些没有任何逻辑。拿sylar举例子，在封装线程的时候，考虑到每个线程的名字不同，所以需要某种方式，在“全局”上定义一个变量名为：thread_name的变量，但是，此全局仅针对某一个线程。再比如，sylar在编写协程调度器时，每一个线程都需要记录自己当前正在运行的协程，以及该线程所绑定的调度协程，基于这两个协程才能实现协程任务的调度。 具体细节读者可以参考sylar协程调度器的实现。这里同样需要在“全局”上定义一个变量，此全局是各个线程所独享的“全局”。这点很重要。

实现的可选方案

C++方式定义线程局部变量

C++定义线程局部变量的方式特别简单，就是在全局声明一个变量的时候，在前面加上thread_local关键字即可。在每个线程被创建初始化时，会各自创建同名，但不同对象的变量。也即：线程内部共享，但是线程之间独享的“全局变量”。

本文主要讲解ANgular在Windows平台的环境搭建。

安装Node.JS

1. 官网下载稳定版本的node.js：https://nodejs.org/en/

2. 安装对话框一路默认下一步，当然，可以按需修改安装路径。

3. 安装完成后会自动将Node.JS的根目录添加到环境变量，读者可以自行查询。

4. 在nodejs根目录,创建node_global，node_cache文件夹

5. 以管理人员身份运行CMD。输入如下命令：