Project RC

一只腊鸡的技术成长。

我的 2018 年

创建于
分类:Misc
标签:闲扯

2018 年的最后一天是时候总结一下这一年都干了什么了~

一年的计划回顾

今年刚开始的时候打算学的东西基本上全都了,比如:

  • 网球
  • 滑板
  • 概率论
  • 计算机网络
  • 编译原理
  • 日语

年初的时候算是学了些计算机组成原理和体系结构相关的东西,然而并不深入……其它的时间基本上都花在水项目上了。

今年看了的书

  • 《苏菲的世界》
  • 《C++ Primer》
  • 《算法》
  • 《数字电⼦技术基础》
  • 《数字设计和计算机体系结构》
  • 《汇编语言》
  • 《计算机组成与设计》
  • 《精通比特币》

除了《精通比特币》,其它基本上都是今年上半年看的,之后就没怎么看过书,一直在写代码了。

今年值得记住的「第一次」

  • 第一次去酒吧
  • 第一次跑 10 公里
  • 第一次实习
  • 第一次加班
  • 第一次面试别人
  • 第一次在外地过生日
  • 第一次辞职
  • 第一次被租房中介坑
  • 第一次做菜
  • 第一次组建社团
  • 第一次开培训班

项目

今年主要用的编程语言是 Python 和 C++,主要维护的项目全都是跟 QQ 机器人相关的:

  • coolq-http-api
  • coolq-cpp-sdk
  • python-cqhttp
  • python-aiocqhttp
  • nonebot
  • amadeus

社交

首先,最重要的!收获了一个无敌可爱的女朋友,让我整个人都变可爱了!在一起经历了很多事情,有开心也有难过,希望以后也能一直走下去!

今年在 CQHTTP 插件的交流群里也认识了很多新朋友,面了很多次基。真的很感谢写这个插件的经历,不仅在项目经验上有很大提升,也认识了很多很志同道合的朋友。

下半年接近年末的时候开始尝试组建开源软件协会,在学校也认识了很多有趣的人,有 18 级的小学弟们,还有其它年级以前不曾了解的大佬们。

新年计划?

看到开头咕了的那些了吗,计划的结果就是这样的,还计什么划。

感觉一次计划一年是非常不切实际的事情,一年的时间太长了,有太多太多无法确定的事情,2018 年的计划我坚持执行到了 6 月,但最终还是变成了想到啥干啥。这么看来也许可以半年订一次计划,应该能够更容易实现一些。

嘛,明天再说吧,先放松放松,享受今年最后的几个小时吧!

我的 2018 年

基于 QDP 协议实现 HTTP 代理

创建于
分类:Dev
标签:QDP代理HTTP代理通信协议QQ酷QCQHTTP

动机

简单实现了 QDP 之后,想通过这个协议寻求对计算机网络一些知识的深入学习,通过跟朋友们的交流,知道了可以通过实现 TUN/TAP 虚拟网络设备来兼容现有的 TCP/IP 协议栈,这是一个有趣的方向,不过还是打算先验证一下自己最开始的想法,也就是基于 QDP 实现一个 HTTP 代理,算是学习和实践一下 HTTP 代理的原理吧。

思路

根据 HTTP 代理原理及实现(一),HTTP 代理的原理,分为两种:第一种,浏览器将请求直接发送给 HTTP 代理,后者将 HTTP 请求转发给服务端(以客户端的身份),随后再将服务端的响应转发给浏览器(以服务端的身份);第二种,浏览器通过 CONNECT 方法请求代理建立一条隧道,通过该隧道转发 TCP 数据。

QDP 协议在这个实验中的作用,实际上是用于在「与浏览器通信的本地 HTTP 代理」(后面称此为「代理前端」)和「用于转发请求到真实目标站点的伪客户端」(后面称此为「代理后端」)之间传输数据,从而让真实的流量通过 QQ 消息传送。

由于 QDP 被用在代理程序的两个部分之间的通信,因此还需要设计一种数据交换协议(实际上是一种 RPC)(后面称此为「代理协议」)来作为 QDP 的有效载荷。

到这里,从思路上来说,整个工作流程已经比较清晰了:代理前端开放 HTTP 代理端口,接受浏览器的代理请求,然后进行必要的处理,再通过代理协议,把必要的数据和指令发送给代理后端,后者根据这些数据和指令,向代理请求的实际目标网站发起连接,并继续通过代理协议在代理前端和目标网站之间转发数据。

实现

第一步首先根据 Jerry Qu 的博客内容来实现一个正常的 HTTP 代理,源码见 demo/http_proxy.py。这一步遇到了一些坑,最后因为没有适当的第三方 HTTP 库,转而直接使用 asyncio 自带的流 API,也算是粗糙地实现了。

接着就是要把代理的前端和后端拆开。

先设计它们的通信协议(上面说的代理协议),为了简便起见,直接使用 JSON 来定义:

{
    "id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
    "method": "connect",
    "params": {
        "host": "www.example.com",
        "port": 443
    }
}
{
    "id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
    "method": "transfer",
    "params": {
        "data": "<base64 encoded bytes>"
    }
}
{
    "id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
    "method": "close",
    "params": {}
}

上面的 id 字段是 UUID,用于唯一标识一个代理请求。method 字段定义了代理协议的三个方法,分别是 connecttransferclose,这三个方法是通过分析先前实现的 HTTP 代理所进行的操作得来的,首先代理前端需要通知后端连接目标站点(使用 connect 方法),然后两端需要互相转发数据(使用 transfer 方法),最后请求完成后还需要关闭连接(使用 close 方法)。params 字段是相应方法所需的参数。

有了代理协议之后,就可以开始分别实现代理前端和代理后端了。

代理前端非常简单,直接在正常的 HTTP 代理的代码上修改。接受代理请求的部分不用动,当需要建立连接的时候,向代理后端发送 connect 协议包;然后当从代理请求的连接中读取数据之后,使用 transfer 协议包向代理后端发送数据,与此同时,当后端发来数据(同样是 transfer 方法)时,从中读取数据并转发给代理请求方(浏览器)。源码见 demo/http_proxy_frontend.py

代理后端不能直接从正常的 HTTP 代理代码修改,需要写一些新的逻辑,主要就是不断地接收代理前端发来的协议包,如果是 connect,就开启一个协程,向目标网站建立连接,然后不断接收对应 id 的协议包,如果是 transfer 则转发,close 则关闭,实际代码不是很多。源码见 demo/http_proxy_backend.py

上面代码虽然说起来简单,但实际编写的时候还是经历了一些艰难的 debug 的……由于代码量不算非常多,就没怎么加注释了,阅读起来应该不会很困难。

效果

编写代码时代理前后端都是跑在本地的,测试成功后,将后端和其对应的 QQ 移到阿里云上海的某个 VPS,成功运行,访问 ip.cn 来验证 IP 地址确实已经是阿里云上海的地址:

从上图的 DevTools 可以看出,这个代理的速度基本上慢到不可用了(本来 QDP 就已经足够慢了,现在代理协议又需要占用额外的空间),但作为一个概念验证已经足够了。

参考资料

基于 QDP 协议实现 HTTP 代理

QDP:一种以 QQ 消息为传输介质的通信协议

创建于
分类:Dev
标签:QDPUDP通信协议QQ酷QCQHTTP

QDP(QQ-based Datagram Protocol)是一种基于 QQ 消息的传输协议,可用于通过 QQ 传输任意二进制数据,并自动对数据报进行分片发送。

协议实现见 richardchien/qdp

动机

上面的描述听起来很诡异,但确实是这样。

起因是做 CQHTTP 插件的时候想基于 酷Q 写一个新的 QQ 客户端,然后想到可以通过 QQ 消息发送一些 QQ 自己的客户端不支持的内容,比如 Markdown,再由这个第三方客户端来进行解析和显示,进而意识到其实可以通过 Base64 等编码来使任意二进制数据的传输称为可能。

和朋友讨论的过程中也意识到其实这个东西理论上可以用来做隧道代理(虽然速度会非常非常慢)。

这个想法在脑海里搁置了很久之后,终于闲 xian 来 de 无 dan 事 teng 来设计了一下协议的具体内容并做了简单实现。

思路

首先,QQ 消息只能发送文本内容,而我们想实现任意二进制的传输,因此需要把二进制转换成字符串,既然是概念验证,肯定就选最简单的 Base64 了。

然后,考虑到发送的二进制内容可能非常大,编码之后可能会超出 QQ 单条消息的允许大小,经过简单测试,发现一条消息可以发送 4500 个 ASCII 字符,也就是说,一条消息最大能发送 4500 字节,这里我们记 QQ 消息的 MTU 为 4500 B。

这个 MTU,实际上不能全部拿来传输数据,因为我们要能够确保知道这条消息是 QDP 协议的数据,还需要一些标记手段,这里通过在 Base64 编码之后的消息开头加上魔术前缀来实现,例如 <<<42>>>~,只有消息以这个前缀开头,接收方才会去尝试解包它之后的 Base64 内容。于是消息内容最终长这样:

<<<42>>>~elkAATA5xexIZWxsbywgMTIzIQ==

再考虑 QQ 机器人发送消息的频率不能无限高,实际上这个频率只能很低,否则很容易被封号,经过和相关机器人开发者的讨论,这个频率应该能够达到最高 10 msg/s 左右,但这只是发送频率,实际接收方接收消息的速度会更慢。

另外,QQ 消息有一个特点是,消息之间有可能乱序,甚至有可能丢失,但只要是收到的消息,几乎不可能出错,类比计算机网络中现有的 TCP、UDP 等协议的话,QDP 协议是不需要校验和的,因为只存在乱序和丢包,不存在内容出错。

由于这只是概念验证,于是不打算实现像 TCP 那样的可靠传输,实际上 QQ 消息在一定程度上已经非常可靠了,虽然说有可能出现乱序,但在网络条件比较好的测试环境应该还是可以忽略不计。

UDP 协议使用源 IP、源端口、目标 IP 和目标端口来确定数据报的发送和接收方,但 QQ 上没有 IP,因此这里使用源 QQ、源端口、目标 QQ 和目标端口来确定发送和接收方。于是,模仿 UDP 协议的首部,QDP 的首部需要包含源端口和目标端口。而 QDP 数据报最终发送时,需要经过类似于 IP 分片的处理,也就是把 QDP 数据报当做数据,切成多块之后再各自加首部,形成新的大小在 MTU 允许范围内的数据报,本来想把这一层称为「QIP」,但实现的时候发现没必要这么复杂,所以这个概念就不要了,这个切分之后的分片,我们称之为「QDP 分片」。如果模仿 IP 协议的话,「QDP 分片」的首部需要包含源 QQ、目标 QQ、数据报 ID(用于重组分片)、分片偏移,但这里我们进行简化,因为我们通过 QQ 收发消息,收发消息的时候都能够知道自己和对方的 QQ 号,不像真实的网络那么复杂,因此实际上分片中是不需要放源和目标 QQ 号的。而 IP 的分片偏移在实现上也似乎有点繁琐,因此 QDP 分片直接使用序号了。

根据上一段的思路,最终 QDP 数据报(Packet)和 QDP 分片(Fragment)的协议格式设计如下:

QDP Packet
+------------------+------------------+------------+
|      16 bit      |      16 bit      | var length |
|     Src Port     |     Dst Port     |    Data    |
+------------------+------------------+------------+

QDP Fragment
+------------------+-------+----------+------------+
|     16 bit       | 1 bit |  15 bit  | var length |
|    Packet ID     |  MF   | Sequence |    Data    |
+------------------+-------+----------+------------+

其中,QDP Fragment 的 Data 是整个 QDP Packet 的二进制切分之后的一部分,QDP Packet 的 Data 是实际要传输的二进制内容;Packet ID 是对应一个 QDP Packet 的随机数,用于接收方对可能有多个数据报混杂的分片进行重组;MF 标志位就和 IP 数据报的 MF 一个意思,More Fragment,表示当前分片是不是最后一个分片;Sequence 表示当前分片是原始 QDP Packet 的第几个分片,从 1 开始数。

有了协议格式之后,整体的收发流程就比较明确了。

发送方指定目标 QQ、目标端口和数据,QDP 实现程序将源端口、目标端口和数据放入 QDP Packet,按需进行切分,组成一个或若干个 QDP Fragment,然后依次将每个 QDP Fragment 的内容的二进制进行 Base64 编码,加上魔术前缀 <<<42>>>~,发送给目标 QQ。

接收方收到 QQ 消息,判断是否以魔术前缀开头,如果是,将前缀之后的内容进行 Base64 解码,恢复成 QDP Fragment,判断 MF 标志位,如果不是最后一个分片,暂存该分片,如果是最后一个,则根据 Sequence 进行排序重组,如果出现分片丢失的情况,直接丢弃该数据报。成功重组之后得到 QDP Packet,判断其目标端口是否为当前应用监听的端口,如果是,则放入 Socket 对应的接收队列,等待应用程序接收。

实现

上面思路的最后已经详细说明了协议的具体工作流程,因此实现起来就非常简单了,见 richardchien/qdp

上面给出的实现提供了如下接口(很类似于 Python 内置的 UDP Socket 接口):

qdp.init({
    12345678: 'ws://127.0.0.1:6700'
})

sock = qdp.Socket()
await sock.bind((12345678, 9999))
logging.info('QDP socket created')

while True:
    data, addr = await sock.recvfrom()
    text = data.decode('utf-8')
    logging.info(f'Received from {addr[0]}:{addr[1]}, data: {text}')
    text_send = f'Hello, {text}!'
    await sock.sendto(text_send.encode('utf-8'), addr)
    logging.info(f'Sent to {addr[0]}:{addr[1]}, data: {text_send}')

上面的代码给出了一段使用 QDP Socket 实现服务端的例子。qdp.init() 传入 QQ 号和 CQHTTP 的 WebSocket API 地址的映射;sock.bind((12345678, 9999)) 将 Socket 绑定到了 QQ 12345678 的 9999 端口;sock.recvfrom()sock.sendto() 就是非常正常的接收和发送接口了。

客户端部分的代码基本上和服务端类似,和 UDP 的区别是,即使是客户端,也必须要调用 sock.bind() 方法,来绑定到 QQ 号(因为要连接 CQHTTP),端口可以填 None,内部会从 50000 到 65535 随机选取一个可用端口。

另外,由于发送大量数据时需要分很多片,为了限制消息发送频率,顺便给 CQHTTP 写了一个 API 限速功能,可以通过配置文件限制请求的执行速度,测试时使用了 2 msg/s 和 5 msg/s 两种速度。

总结

以上就是 QDP 协议从理论上的概念到实现的过程了,实现之后简单进行了一下测速,发现每秒实际只能传输 2~3 KB 的数据,可以说非常慢了,基本上没啥用,不过作为概念验证已经算是成功了。

参考资料

QDP:一种以 QQ 消息为传输介质的通信协议

在笔记本上使用 Proxmox(或其它 Linux 服务器版)时关闭屏幕

创建于
分类:Ops
标签:LinuxProxmox

给吃灰许久的 12 年款 MacBook Pro 装了个 Proxmox 玩玩,发现启动后屏幕一直亮着,提示登录,搜了一圈找到 AskUbuntu 上有个同样的问题,这个答案 完美的解决了问题:

setterm --blank 1

这条命令的效果是,不操作一分钟后自动关闭屏幕。

另外,一直开着盖子,键盘上会落灰,盖上之后发现机子掉线了,也搜了一下,发现 这个答案 完美解决了问题:

修改 /etc/systemd/logind.conf 中的

#HandleLidSwitch=suspend

HandleLidSwitch=ignore

然后

service systemd-logind restart

之后合盖就不会睡眠了。

在笔记本上使用 Proxmox(或其它 Linux 服务器版)时关闭屏幕

VeriPress 主题集合

创建于
分类:Misc
标签:VeriPressBlogThemeCollection

目前 VeriPress 已经有了好几个官方和第三方主题,为了便于查找,这里做一个集合列表。

主题名 预览/截图 简介
default Preview 为博客设计的默认主题
clean-doc Preview 为文档设计的默认主题
fenki - 为 Wiki 设计的默认主题
richardchien/veripress-theme-r - 一个简洁的纯色博客主题
richardchien/veripress-theme-light Preview 一个风格小清新的博客主题,样式比较轻快
txperl/Story-for-VeriPress Preview 一个适合写作与阅读的博客主题
momocow/veripress-theme-suka Preview Modern, powerful and simple theme ported from Hexo.

以上的主题均可以直接通过:

$ veripress theme install 主题名

来安装,并可通过:

$ veripress theme update 主题名

来更新。

VeriPress 主题集合

使用位置模拟器进行步道乐跑的跑步打卡

创建于 更新于
分类:Misc

这学期学校突然非常贴 zhi 心 zhang 地引入了「步道乐跑」这一软件来完成大学生阳光体育的政策要求(以前是去体育场刷卡),简单了解了一下发现这个软件非常臭名昭著——随机打卡点、只使用 GPS 定位导致路线记录不准、对较新版本 Android 系统兼容性不好等。

对于这种强迫我们在危险的大马路上跑步、还经常需要停下来低头看手机的黑恶势力软件,乖乖听话是不可能的,于是花了点时间研究了一下另类方法。

准备

首先你需要准备一部已经 root 的 Android 手机,具体怎么 root 这里就不说了。

注意,如果你没有接触过 root,那么需要小心谨慎地详细了解一下,因为 root 操作比较危险,会让手机变得不安全,尽量在备用机上操作。

我一开始尝试了在夜神模拟器里面运行,结果步道乐跑会检测蓝牙状态,夜神模拟器不支持蓝牙,于是放弃了,不过 Genymotion 这种是有可能可以的,因为它也模拟了蓝牙等传感器。

目前发现前几天还可以用的情况下,某天乐跑突然又说检测到模拟器了,推测是通过热更新增加了对 root 的检测,换用 Magisk 进行 root 之后,通过 Magisk Hide 功能对乐跑隐藏了 root,似乎解决了,不过并不十分确定是因为检测 root。

安装 Xposed

这里 帖子底下的附件 XposedInstaller_3.1.5.apk(实际版本号可能不同)链接下载 Xposed Installer,然后安装。

打开之后会看到如下红色感叹号:

红色下面是下图:

点「Version 89」(具体版本可能不同),然后弹窗中选「Install」即可安装,安装之后需要重启手机。

完成之后红色感叹号会变成绿色的对号:

此时即为安装成功。

安装大牛助手(位置模拟器)

大牛助手是一款利用 root 权限模拟定位的软件,目前最新版是收费的,但旧的 1.1.7 版本是免费的,虽然它强制更新,但可以用 Xposed 模块来强行关闭弹窗。

1.1.7 版本可以从 这里 下载。

安装之后别急着打开,开了也千万不要更新,直接退出。

然后下载安装 对话框取消 Xposed 模块,安装之后需要在 Xposed Installer 的「模块」中勾选,然后重启手机。

重启之后打开对话框取消模块,勾选「开启模块」和「开启增强模式」,然后在下面的应用列表找到大牛助手,进行如下配置:

然后点保存并重启,之后打开大牛助手应该就不会出现强制升级的弹窗了。

运动模拟器

步道乐跑最让人诟病的就是它只通过 GPS 来确定跑步路线和距离,而没有通过陀螺仪等运动传感器来辅助判断,也正因为这一点,不需要开运动模拟器也可以模拟跑步,不过,为了保险起见,目前步道乐跑后台应该是会检查客户端上传的数据中的运动步数,过低会判断为代步工具嫌疑,这个可以通过安装 Xposed 模块 运动模拟器 来模拟运动步数,具体方法这里就不详述了,和「对话框取消」的安装方法基本上一样。

安装步道乐跑

就在应用商店正常安装即可,不过我安装的是一个旧版本,并不确定新版本中下面的方法是否还有效。

旧版本下载地址:链接: https://pan.baidu.com/s/1GMiGWocpXEJqX8yfypRIIA 提取码: abib

如果你安装的是旧版本,那么需要像上一步那样对步道乐跑也启用对话框取消,否则它也会弹窗强制更新。

防止步道乐跑检测到位置模拟器

步道乐跑会「检测」手机中是否有运动模拟器,经过一番研究,发现实际上它是通过获取手机的应用列表来判断的,当发现 Xposed Installer、大牛等应用,就会提示你要诚信跑步。

好在大牛助手有 app 防检测功能,进入大牛的 app 防检测,添加大牛和 Xposed Installer 两个应用,选择防止步道乐跑检测,即可。

模拟跑步

具体模拟跑步时,首先进入步道乐跑,然后点进跑步界面,当出现地图之后,就会出现第一个打卡点。

然后打开大牛,使用「路线模拟」功能添加两个点,第一个点是你的当前位置(或任意学校内的位置),第二个点是步道乐跑的打卡点,然后在「配置」页面调整速度,根据步道乐跑要求的平均配速(3~9 分钟 1 km),设置速度为 10 km/h 左右,然后保存并开启路线模拟。

这时候大牛就已经开始模拟位置的变化了,切换到步道乐跑,点开始跑步,然后等它打卡成功,之后出现下一个点,回到大牛,停止路线模拟,删掉第一个点,再添加新的打卡点,然后再次开启模拟,再切回步道乐跑。

第三个打卡点以此类推,三个点全部打完就可以结束跑步了。为了避免在大牛那边的操作耗时导致配速不符合要求,可以适当提高大牛的模拟路线的速度,或者在切换到大牛之前先暂停跑步。

最后

其实步道乐跑这软件,或者说大学生阳光体育运动,它们本身的动机是好的,现在大学生天天宅在宿舍里确实需要运动,但这样强制通过跑步的方式来运动,为了避免作弊还一定要在校园内随机打卡地点,还花了很多精力去检查系统环境、检查模拟器,就显得有些病态了,搞得本来就喜欢运动的人也需要百般折腾。

虽然这里给出了破解方法,但还是建议抽出一些时间去真实地做一些运动,毕竟身体健康还是很重要的。

使用位置模拟器进行步道乐跑的跑步打卡

使用 Netlify 部署 VeriPress

创建于
分类:Misc
标签:BlogVeriPressNetlify

博客好久没更新,最近突然想重整一下,于是重新写了个 主题,样式是抄的以前 LiveChat 的官方博客的样式(现在他们的博客已经不长这样了)。

然后之前把博客迁移到 GitHub Pages,用 VeriPressgenerate 命令生成之后 push 到 GitHub,现在觉得还是有点麻烦,从 VuePress 那边学到了部署到 Netlify 这招,就想着能不能把 VeriPress 也部署到 Netlify,后来折腾了一下发现可行。

首先需要看 VeriPress 生成静态文件的步骤(已经创建 instance 目录的情况下):

veripress theme install theme-name
veripress generate

这里安装主题这一步是必须的,所以导致 VeriPress 最少也需要两行命令,再加上主题允许自定义的 custom 目录,实际可能需要更多命令才能完成静态文件的生成,于是考虑用一个 shell 脚本,这样在 Netlify 那边的 build 命令就只需要填写 bash build.sh 就行了,我的 build.sh 如下:

#!/usr/bin/env bash

veripress theme install richardchien/veripress-theme-light --name light

theme=`python -c "import config; print(config.THEME)"`
rm -rf ./themes/$theme/templates/custom
cp -R ./theme-custom ./themes/$theme/templates/custom

veripress generate --app-root=/

然后再添加两个文件 runtime.txt

3.6

requirements.txt

veripress

分别告诉 Netlify 运行所需的 Python 版本和依赖项。

最后去 Netlify 添加站点,build command 填 bash build.sh,publish directory 填 _deploy 就可以了。

以后写博客只需要将 VeriPress 实例的目录整个 push 到 GitHub(我忽略了 themes 目录),之后 Netlify 会自动生成静态文件然后部署,可以说非常棒了~

使用 Netlify 部署 VeriPress

记一次关于 C++ 多线程写文件操作的错误修复

创建于
分类:Dev
标签:C++Multithreading

前段时间酷 Q HTTP API 插件有用户报错说,连续请求两次 API 发送同一张图(通过 URL),会发生第二张图发不出去的问题。想了一下,问题很显然,因为插件在处理第一个请求的时候,开始下载图片,以 URL 的 md5 作为文件名,然后第二个请求到的时候(多线程处理),图还没有下完,但是同名文件已经存在了,插件以为是缓存,于是试图直接发送下到一半的文件,自然是发不出去了。

最简单的修复方法是让插件先把图片下载到一个临时文件,下载完成后再改名。但是这样的话,两个请求都会造成文件下载,但实际上这是不必要的,因为它们实际发的是同一张图。那么自然要想到让第二个请求发现已经有请求在发送同一张图的时候,等待其完成,然后直接发送已缓存的图。

一开始想到用一个 std::map<std::string, std::mutex> 来按文件名保存互斥锁,每个线程首先算出文件名,然后尝试获取文件名对应的锁。这个方法看起来虽然好像可以,但实际上仔细一想发现了问题,std::map 本身就不是线程安全的数据结构,两个线程很可能在创建和删除锁的时候发生冲突,而如果再给 map 加个锁,逻辑就开始有些混乱了,有发生死锁的风险。

于是去 Stack Overflow 搜了一圈,发现了 std::condition_variable 这么个东西,通过 waitnotify_onenotify_all 方法来实现让线程等待和唤醒等待中的线程,基本上满足了我的需求。

最终修复代码如下:

static unordered_set<string> files_in_process;
static mutex files_in_process_mutex;
static condition_variable cv;

if (!filename.empty() && make_file != nullptr) {
    unique_lock<mutex> lk(files_in_process_mutex);
    // wait until there is no other thread processing the same file
    cv.wait(lk, [=] {
        return files_in_process.find(filename) == files_in_process.cend();
    });
    files_in_process.insert(filename);
    lk.unlock();

    // we are now sure that only our current thread is processing the file
    if (make_file()) {
        // succeeded
        segment.data["file"] = filename;
    }

    // ok, we can let other threads play
    lk.lock();
    files_in_process.erase(filename);
    lk.unlock();
    cv.notify_all();
}

使用一个 std::unordered_set<std::string> 保存了当前正在处理的请求对应的文件名,同时对应有一个互斥锁。

第一部分首先获取互斥锁,然后调用 std::condition_variablewait 方法,这个方法会首先判断传入的谓词(第二个参数)是否满足(在拥有锁的情况下调用),如果不满足,释放锁,然后等待(阻塞当前线程)。在第一个 API 调用时,显然并没有其它线程正在处理同名文件,所以它会往下执行,把当前文件名放到集合,然后释放锁(这是很重要的,在实际下载文件开始之前需要释放锁,否则下载别的文件的线程也得等这个线程执行完才能执行)。

第二部分就是下载文件操作了,这里之所以不用拥有锁,是因为我们在第一部分已经确定没有其它线程正在操作这个文件,而一旦文件名插入到集合中(拥有锁的时候插入的),别的下载同名文件的线程就会在 wait 方法里阻塞了。因此第二部分我们可以确定每个文件只有一个线程在下载。

第三部分就是下载完成后从文件名集合中删除当前文件名了,在拥有锁的情况下删除,然后立即释放锁,接着调用 notify_all,还记得其它需要发送同名文件的线程都在 wait 中等待吗,调用 notify_all 之后它们会被唤醒,然后依次获取锁、判断谓词是否满足,当第二个发送同一图片的线程执行到第二部分的时候,它会发现图片已经缓存了,于是直接发送缓存了的图片。

至此完美解决了一开始的问题。

记一次关于 C++ 多线程写文件操作的错误修复

使用 PyInstaller 将 Python 程序打包成无依赖的可执行文件

创建于
分类:Dev
标签:PythonPyInstaller

本文以 Windows 为例,其它系统上应该坑会更少一点。

安装

首先一点,截至目前(17 年 6 月),PyInstaller 还不兼容 Python 3.6,根据官方的说明,目前支持的版本是 2.7 和 3.3 到 3.5。当你看到这篇文章时,可能已经支持更新版本了,建议查看官方 repo 的 README:pyinstaller/pyinstaller

用 pip 安装:

pip install pyinstaller

在 Windows 上,pip 会同时安装 pypiwin32 包,这是 PyInstaller 在 Windows 上的一个依赖。

这里就有了第一个坑,根据 Requirements

It requires either the PyWin32 or pypiwin32 Python extension for Windows.

理论上应该默认情况下安装了 pypiwin32 就可以运行的,但其实并不行,直接用的话会报错 ImportError: DLL load failed: The specified module could not be found.

根据 #1840 这个 issue,再安装个 PyWin32 就可以了。

前往 Python for Windows Extensions,点进 pywin32 目录里面的最新 build,找到对应当前 Python 版本的 exe,下载安装。

使用

比如我们现在有一个脚本文件 main.py,要将它打包成可执行文件,直接运行:

pyinstaller -F main.py

这将会在 main.py 所在目录下生成一些其它目录,最终的可执行文件就在 dist 目录中。这条命令中 -F 表示生成单个可执行文件,如果不加 -F,则默认生成一个目录,其中除了可执行文件,还包括其它依赖文件。

总体来说用起来是非常简单的,不过在打包使用了 requests 包的程序时,出现了 ImportError: No module named 'queue' 的报错,发现 这里 也有遇到了同样的问题。

这个问题只需要在打包时加入 --hidden-import 参数即可:

pyinstaller -F --hidden-import queue main.py

更多用法请参考 Using PyInstaller

使用 PyInstaller 将 Python 程序打包成无依赖的可执行文件