0%

维护的项目代码有很多编码不是utf-8的,导致保存会把中文注释变成乱码

不止我一个人遇到这个问题,项目中有很多已经是乱码文件是别人导致的

我研究了一下,把文件用utf-8或者gb2312打开,再转换成gbk繁体,如果转换失败,那基本就是乱码

代码如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
import os

def check_is_encode_error(string):
try:
string.encode('gbk')
except UnicodeEncodeError:
return True
return False

def check_file(filepath):
try:
with open(filepath, "r", encoding="utf-8") as file:
lines = file.readlines()
except UnicodeDecodeError:
with open(filepath, "r", encoding="gb2312") as file:
lines = file.readlines()

for num, line in enumerate(lines, 1):
if check_is_encode_error(line):
print("文件存在乱码 {}:{}".format(filepath, num))

def check_dir(dir):
for root, dirs, files in os.walk(dir):
for file in files:
filepath = os.path.join(root, file)
try:
check_file(filepath)
except:
pass
print("文件 {} 检查失败".format(filepath))

# 把"path_to_dir"替换成你要检查的文件夹
check_dir("path_to_dir")
阅读全文 »

最近的几个系统都用到了定时更新配置

获取到的配置是需要高频使用的,不能直接使用字符串

需要预处理为整数或浮点数,甚至是一个整数数组

因此整理了一下Config设计:

分为元数据Meta,配置的存储和注册Config两个模块

阅读全文 »

在维护网络库时,总能遇到一些没太大用处,但是很有意思的小知识,细细碎碎又不成体系,记录一下

异步的epoll使用

  • 2015.5.22整理:

    epoll下LT和ET的处理都是大致相同的

    • LT模式

      读buff有数据 / 写buff有空间,就触发

    • ET模式

      读buff有数据,且数据减少或调用epoll_mod时 / 写 buff 空间增加或调用epoll_mod时,才触发

    LT模式例子:

    https://www.cnblogs.com/lojunren/p/3856290.html

    https://github.com/hurley25/ANet

    https://juejin.im/post/5ab3c5acf265da2380598efa

    https://www.zhihu.com/question/22840801

    https://blog.codingnow.com/2012/04/mread.html

    在ET模式中,需要主动把数据读完或者写满:

    • 读处理是一直read

      返回-1,检查errno,如果是EAGAIN那么不再读(缓冲区读完),如果是其他那么说明连接出错,进行报错然后也不再读。

      返回0,说明对端关闭

      返回大于0,成功读到数据

    • 写处理是一直write,直到数据写完

      返回-1,检查errno,如果是EAGAIN那么不再写(缓冲区写完),如果是其他那么说明连接出错,进行报错然后也不再写。

      返回大于0,成功写数据

在使用tcp时,内核的tcp上存在读写缓冲区,上层app通过这个缓冲区来和实际的网络进行通信

app <=> 内核tcp <=> network

阅读全文 »

本文主要讲述了Borg论文中引用的基于机会成本的E-PVM算法

这个算法的缺点(大型任务难以调度)是在我的场景下是可接受的

对Borg来说,任务实际是一个任务组,亲和需求的任务组需要特别多的资源

而在我的调度问题中,大型任务是很少的,因为我的调度器不提供任务组的概念,由业务来解耦任务组

我尝试理解该算法后做一些优化,然后通过模拟器模拟和分集群测试来查看是否可以提升资源利用率

阅读全文 »

Bistro

《Bistro: Scheduling Data-Parallel Jobs Against Live Production Systems》

facebook2015年论文,用于解决离在线混部时,约束离线任务运行在指定资源范围的问题

  • 提出了一种基于树模型的资源调度问题

    例如叶子节点是数据库卷,上面的父节点是主机,机架等等

    在任务退出时,对影响到的叶子节点以及父节点(直到根节点)进行调度,来避免全部资源池的调度太过耗费性能

Bistro在架构上允许对树的独立资源的根节点,哈希或者按位置进行分区,从而进行并行调度和分布式调度

阅读全文 »

我在整理tars和taf的协程逻辑的时候,也实现了一个纯净版的协程框架以便于理解

是基于我6年前编写的网络框架sheep_cpp修改的,虽然当年在魅族也是生产环境的网络框架,但是以我目前的经验来看,还是有很多不足的地方

仅作为演示协程实现的代码应该还是绰绰有余的,协程和协程套件的单元测试全部正常运行,用例在https://github.com/tedcy/sheep_cpp/blob/master/test/coroutine/coroutinue_test.cpp

网络框架

网络框架部分最大的问题还是单线程模型了,成熟的框架都是网络线程和工作线程分离的

阅读全文 »

最近大概间隔1个月,我在使用定时任务类时遇到了两次析构过程中的 bug

这两个 bug 出现在我用别人写的定时任务类时,这两个bug的区别是一个是组合使用的,另一个是继承使用的

由于coredump的堆栈都不在正常的位置,因此这两个bug都花费了我平均一整天的大量时间去定位

另外有个基于协程的定时任务类,这个类不仅只是使用,甚至都是我实现的,尽管 bug 还未发生,我仔细看了下居然也存在类似的问题

因此,我觉得我有必要总结这个问题,避免再次在相同的问题上耗费太多时间,毕竟多线程(协程)问题的定位非常困难

阅读全文 »

本文续接锁实现分析:从glibc到futex(一)

上一篇对glibc和futex进行了源码分析,是我对具体实现的梳理,没有总结性的内容,可以略过不看直接看这一篇总结

本篇总结尝试深入一些,继续挖掘锁这个概念

分析内核在实现锁的过程中是如何解决无效唤醒问题的

为了解决无效唤醒问题,纯用户态的互斥锁性能不够好;纯内核态又在非竞争的条件时需要陷入内核,从而诞生了futex

阅读全文 »

之前在理解条件变量时在futex上误入歧途,导致犯下死锁的错误,并且写下了错误的博文,见浅析条件变量

所以打算重新理解一下futex

虽然初衷是futex,但是由于futex最初是为了优化锁的性能而提出,因此深入理解futex实际上是对锁概念的深入了理解

因此本篇的大纲

源码分析从c++的mutex开始,然后是glibc的nptl库pthread_mutex,接着是linux内核的futex实现

阅读全文 »