前言
USART串口传输能实现信息在设备之间的点对点传输，支持单工、半双工、全全双工，一般是有三个引脚：TX、RX、SW_RX（共地）。不需要一根线来同步时钟。最大优点是可以和电脑通信，实现程序调试的功能。
导航
图248 USART框图：
图片引自STM32 F1XX系列的中文参考手册。
LevelDB源码阅读笔记（2、SSTable源码分析）
LeveDB源码笔记系列：
前言
本文讨论的Key都是LevelDB里面的Internal Key，至于什么是Internal Key请看LevelDB源码阅读笔记（1、整体架构）。另外本文的源码分析涉及Bloom过滤器的应用，不懂什么是Bloom过滤器的读者需自行学习。
SSTable的结构有关的的文件全部放在table目录下：
LevelDB源码阅读笔记（1、整体架构）
LeveDB源码笔记系列：
前言
对LevelDB源码的博客，我准备采用总-分的形式进行记录，我觉得先了解一下LevelDB整体流程，再往后讲解各个基础组件的话，读者会更容易理解这样设计的用意。
性能简介
数据参考自leveldb的README：https://github.com/google/leveldb。
Qt快速入门（Opencv小案例之人脸识别）
Qt快速入门（MV架构之TableView + QStandardItemModel + 自定义代理小案例）
关于MV架构的简单介绍
在Qt框架中，代理（Delegate）、模型（Model）和视图（View）之间的关系构成了MVVM（Model-View-ViewModel）架构的一部分，尽管Qt通常使用Model-View架构。这三者之间的关系可以这样理解：
1. Model（模型）
Model是数据的核心代表，它负责存储和管理应用程序的数据。Model提供了数据的接口，允许View查询和修改数据。Model与View的交互是通过信号和槽机制来完成的，当Model中的数据发生变化时，它会发出信号通知View进行更新。
2. View（视图）
View是Model数据的展示层，它负责将数据以用户友好的形式展示出来，并接收用户的交互操作。在Qt中，View通常是通过一些控件来实现的，比如QListView、QTableView、QTreeView等。View不处理数据的逻辑，它只是简单地展示Model提供的数据。
3. Delegate（代理）
MIT6.5840（原MIT6.824）Lab2总结（Raft）
资源分享：
官网地址：http://nil.csail.mit.edu/6.5840/2023/
Raft论文地址：http://nil.csail.mit.edu/6.5840/2023/papers/raft-extended.pdf
官方学生指导（又称官方避坑指导）：https://thesquareplanet.com/blog/students-guide-to-raft/
总结：
简单来说，Raft算法是：可以让一条数据备份到多台机器上，而在外部看来，好像只有一台机器的样子。 ，实验做完到现在，也过去了很久了，在这里只能模模糊糊还原当时遇到的一些印象比较深的BUG，千言万语，还是亲身体验一下这些坑，印象才会深刻。
CMU15445实验总结上(Spring 2023)
背景
菜鸟博主是2024届毕业生，学历背景太差，导致23年秋招无果，准备奋战春招。此前有读过LevelDB源码的经历，对数据库的了解也仅限于LevelDB。奔着”有对比才能学的深“的理念，以及缓解自身就业焦虑的想法，于是乎在2024.2.16日开始CMU15445（关系性数据库）实验之旅。目前进度：将P2做完了。
所以，本博客仅是对p1（Buffer Pool）和p2（B+Tree）的总结。
因为C++的基础还凑合，而且时间紧迫，于是跳过了p0实验，建议之前没学过C++同学，可以做做p0以熟悉现代C++的语法。
资源分享：
课程主页链接：https://15445.courses.cs.cmu.edu/spring2023/
B站有一位up主“Moody-老师”，对着CMU15445的ppt按照自己的理解复现了每一次的讲座，链接如下：https://space.bilibili.com/23722270
LevelDB源码阅读笔记（0、下载编译leveldb）
重写Sylar基于协程的服务器（6、HOOK模块的设计）
重写Sylar基于协程的服务器系列：
重写Sylar基于协程的服务器（0、搭建开发环境以及项目框架 || 下载编译简化版Sylar）
重写Sylar基于协程的服务器（5、IO协程调度模块的设计）
重写Sylar基于协程的服务器（7、TcpServer & HttpServer的设计与实现）
简述
HOOK模块存在的必要性：让IO系统调用，以同步写法展现出异步的性能。
hook实际上就是对系统调用API进行一次封装，将其封装成一个与原始的系统调用API同名的接口，应用在调用这个接口时，会先执行封装中的操作，再执行原始的系统调用API。本文实现的是一种利用dlsym函数实现的侵入式hook。
HOOK的实现
首先，是hook重新实现accept函数、socket函数，为了高效的cpu利用率，每个被accept函数接受的socketfd、或者socket创建的fd在返回给调用者前，都会使用fcntl函数，将其设置为非阻塞，虽然socketfd被设置成非阻塞的，但是我们的hook机制，能够利用非阻塞的socketfd实现一种在调用者看来是阻塞的socketfd。
其次，为了获取socketfd的超时时间，所有setsockop也会被hook，如果socketfd之前使用setsockop函数设置超时，其超时时间就会被fdmanager类获取，将超时时间记录在对应的fd上。当然，为了善后，close也会被hook，在调用真正close前，会唤醒相应socketfd上的所有监听协程，让协程退出。
最后，将socketIO有关的系统调用（如read、write、accept等）抽象出一个统一的接口do_io，用户在调用socketIO有关函数时，底层统一调用do_io。do_io流程如下。
进入do_io函数内部，首先会检查socketfd的合法性。
如果socketfd是合法的，就去调用fun。（fun是通过do_io参数传进来的真正的io系统调用函数地址）。
如果sockefd是非法的，也会去调用一次fun，fun返回什么，do_io就返回什么，完全依赖原始的系统底层调用对非法socketfd的处理。
对于合法的socketfd调用fun，由于socketfd是非阻塞的，不管是否读取到数据，fun都会立刻返回。如果读到数据，do_io整体就返回读到的字节数。如果没有读到数据，fun会返回-1，errno为EAGAIN，但是do_io不会返回。
然后调用线程当前的IOManager的addEvent函数，根据用户调用的socketIO相关接口对socketfd添加事件相应读写事件，在addEvent函数内部会把<当前协程，当前协程的协程调度器>放入socketfd对应的EventContext结构体里面，等待socketfd上io事件到来并由idle协程调用TrigleEvent函数唤醒当前协程。
然后调用yieldToHold将协程变成Hold状态，等待socketfd上io事件到来时idle协程将该协程唤醒。
重写Sylar基于协程的服务器（7、TcpServer & HttpServer的设计与实现）
重写Sylar基于协程的服务器系列：
重写Sylar基于协程的服务器（0、搭建开发环境以及项目框架 || 下载编译简化版Sylar）
重写Sylar基于协程的服务器（5、IO协程调度模块的设计）
重写Sylar基于协程的服务器（7、TcpServer & HttpServer的设计与实现）
TcpServer模块架构图
将基于线程的主从Reactor模型进行协程的定制化修改，如图所示。
TcpServer实现
TcpServer类是一个服务器通用类，TcpServer类的实现是Server端专门用来管理Tcp连接的，主要的成员函数及作用如下：
构造函数，用户在构造一个TcpServer时会传三个类型都为IOManager的参数，参数名以功能命名，分别是：worker、io_worker、accept_worker。
bind函数，因为一台服务器有可能有多个<ip，端口>对，所以用户在调用bind函数时，可能会传入多个地址对，bind函数就是负责为这些ip地址创建套接字，并且将ip地址和固定端口绑定，开始监听这些套接字。
start函数，创建accept协程，并将accept协程放到accept_worker协程调度器里面去，accept协程实际上就是回调函数是TcpServer::startAccept的协程。
start函数的伪代码：
startAccept函数，是一个接受客户端连接的回调函数，内部是一个调用accept函数的死循环，在接受到一个socketfd后，将套接字封装成IO协程，并放入io_worker协程调度器中进行调度。IO协程就是回调函数是TcpServer::handleClient函数的协程。
startAccept函数的伪代码：
