1.redis7.0源码阅读：Redis中的IO多线程（线程池）
2.iowrite32写入失败
3.QImage源码分析之Save方法实现

redis7.0源码阅读：Redis中的IO多线程（线程池）

       Redis服务端处理客户端请求时，采用单线程模型执行逻辑操作，然而读取和写入数据的操作则可在IO多线程模型中进行。在Redis中，命令执行发生在单线程环境中，而数据的易语言工具箱源码读取与写入则通过线程池进行。一个命令从客户端接收，解码成具体命令，根据该命令生成结果后编码并回传至客户端。

       Redis配置文件redis.conf中可设置开启IO多线程。通过设置`io-threads-do-reads yes`开启多线程，同时配置`io-threads 2`来创建两个线程，其中一个是主线程，另一个为IO线程。在网络处理文件networking.c中，`stopThreadedIOIfNeeded`函数会判断当前需要执行的命令数是否超过线程数，若少于线程数，则不开启多线程模式，便于调试。

       要进入IO多线程模式，运行redis-server命令，ishow 源码然后在调试界面设置断点在networking.c的`readQueryFromClient`函数中。使用redis-cli输入命令时，可以观察到两个线程在运行，一个为主线程，另一个为IO线程。

       相关视频推荐帮助理解线程池在Redis中的应用，包括手写线程池及线程池在后端开发中的实际应用。学习资源包括C/C++ Linux服务器开发、后台架构师技术等领域，需要相关资料可加入交流群获取免费分享。libcurl源码

       在Redis中，IO线程池实现中，主要包括以下步骤：

       读取任务的处理通过`postponeClientRead`函数，判断是否启用IO多线程模式，将任务加入到待执行任务队列。

       主线程执行`postponeClientRead`函数，将待读客户端任务加入到读取任务队列。在多线程模式下，任务被添加至队列中，由IO线程后续执行。jeebbs源码

       多线程读取IO任务`handleClientsWithPendingReadsUsingThreads`通过解析协议进行数据读取，与写入任务的多线程处理机制相似。

       多线程写入IO任务`handleClientsWithPendingWritesUsingThreads`包括判断是否需要启动IO多线程、负载均衡分配任务到不同IO线程、启动IO子线程执行写入操作、等待IO线程完成写入任务等步骤。负载均衡通过将任务队列中的任务均匀分配至不同的线程消费队列中，实现无锁化操作。

       线程调度部分包含开启和关闭IO线程的功能。在`startThreadedIO`中，joomla源码每个IO线程持有锁，若主线程释放锁，线程开始工作，IO线程标识设置为活跃状态。而在`stopThreadedIO`中，若主线程获取锁，则IO线程等待并停止，IO线程标识设置为非活跃状态。

iowrite写入失败

       CIFS VFS: No response xxx (大概就是这个)

       æˆ‘遇到的这个错误的原因是通过挂载目录传输文件时，每次传输块太大，超过了cifs的缓冲区大小，造成cifs传输延迟。

       cifs读的缓冲区大小最大为K,写的缓冲区大小最大为K(可用"modinfo cifs"这句命令查看参数取值范围).

       åªè¦è°ƒå°ä½ ç¨‹åºçš„传输块大小即可，如下(摘自cifs官方文档Performance Considerations一节)。

       1) size of file write (wsize). The Linux CIFS client usually sends K writes ( pages) and is

       limited to K maximum unless mounted forcedirectio.

       2) size of file read (rsize). The Linux CIFS client usually sends K reads (4 pages). Since CIFS

       large network buffers are about K in size by default, increasing the rsize would have little

       effect unless the setting of module load parameter CIFSMaxBufSize (via insmod) also is

       increased.

       cifs传输速度的优化

       ç¼“冲区调小后，的确是不会报错了，但传输速度却太蜗牛了。

       æ ¹æ®cifs官方文档看，可用调相关参数优化速度(通过modprob.conf这个配置文件加载比较简单)，大家可以都试一下。

       ç½‘上找了很久相关信息，最后确定了forcedirectio这个选项可以优化(大家可以看看本文上面的黑底英文，“除非用forcedirectio挂载”)。

       æˆ‘找到linux源码里的fs/cifs下面的readme，看到里面的参数direct像是forcedirectio的参数,但我加了后传输也没有提高。

       ç”¨"mount.cifs --help"查看选项后才发现direct不是准确的参数，应该是directio 。

       é™„上加参数挂载cifs的格式：

       mount -t cifs //..1.1/source ..1.2/destination -o username=myusername,password=mypassword,directio

       ä½¿ç”¨directio参数挂载目录后，传输速度果然提升不少，速度和windows之间对传文件的速度差不多(我是用大小为K的传输块测试的，能达到M/s)。

       å¦‚果要测试的话可以用"dd if=srcfile out=destfile bs=K"测试，其中bs是在指定传输块大小，我觉得设成K时的传输速度已经很好了。

       å“¦ï¼Œå¯¹äº†ï¼Œè®°å¾—在读写挂载目录文件时使用read/write函数，而不要使用fread/fwrite函数，使用前两者比后两者传输速度快，这跟程序有关了。

QImage源码分析之Save方法实现

       在进行图像处理时，发现使用QImage保存图像时出现错误，问题定位在save方法。通过查看源码，了解到save方法根据传递的格式依赖不同类进行处理。例如，PNG格式由QPngHandler类处理，该类调用第三方库libpng进行操作，解释了错误原因，即可能缺少相应库支持。

       QImage类内部实现中，可以看到QImageData的私有数据结构，其构造函数也使用了QImageData。使用QScopedPointer作为智能指针，存储图像参数如宽度、高度、深度、字节数等。

       save方法有两种实现方式，均通过构造QImageWriter对象来实现，方法参数类型虽不同，但均为QIODevice类型，即用于IO操作。

       整个save流程为：调用QImageWriter构造方法，传递图像和输出设备信息，然后调用writer对象的write方法进行保存。

       深入阅读Qt源码，发现其设计的精妙之处，感受到Qt源码的独特魅力。对于Qt源码的探索，可能会持续沉迷其中。