相关分享
嵌入主线程消息循环的任务调度器
这篇文章记录了 soluna/ltask 在移植到 wasm 和非 Windows 平台过程中遇到的一个典型工程难题:如何在主线程事件循环中执行特定任务,同时仍保留原有多线程调度模型。
问题的核心来自图形 API 和平台约束。sokol 并非线程安全,OpenGL 又依赖当前线程状态,而 wasm 环境下主线程、worker、pthread API 的边界进一步放大了调度复杂度。
作者的解决思路不是重写整个调度器,而是在 ltask 中“打洞”:让某些必须在主线程回调中执行的 Lua 任务,临时从调度表中移出,由主线程接管执行,完成后再归还给调度器。
文章最有价值的地方,是把 coroutine、Lua 虚拟机、C 栈、主线程事件循环和图形 API 约束放在同一个工程场景中分析。它不适合泛泛阅读,但对做游戏引擎、wasm 移植或复杂运行时调度的开发者很有参考价值。
一次消息队列异常堆积的排查
背景前两天收到业务反馈有一个 topic 的分区消息堆积了,根据之前的经验来看,要么是业务消费逻辑出现问题导致消费过慢,当然也有小概率是消息队列的 Bug(我们使用的是 pulsar)。排查通过排查,发现确实是在一点多的时候消息堆积了(后面是修复之后堆积开始下降)。。。
IM服务器设计-如何解决消息的乱序
IM消息需要面对的另一个难题:如何保证收到的消息不乱序。下面先展开看看要解决这个难题有哪些障碍。
IM服务器设计-消息存储
这部分专门讲述IM消息存储的设计。消息存储的难度在于,要考虑以下的场景:
1、离线消息存储。即发送消息时对方不在线该怎么处理。
2、单聊、群聊消息。
3、随着用户量越来越大,应该以后如何扩展。
Go 语言史诗级更新-循环Bug修复
背景前两天 Golang 的官方博客更新了一篇文章:Fixing For Loops in Go 1.22,看这个标题的就是修复了 Go 循环的 bug,这真的是史诗级的更新;我身边接触到的大部分 Go 开发者都犯过这样的错误,包括我自己。
真实世界的Go设计模式 - 对象池模式
对象池(object pool pattern)是一种设计模式。一个对象池包含一组已经初始化过且可以使用的对象,而可以在有需求时创建和销毁对象。池的用户可以从池子中取得对象,对其进行操作处理,并在不需要时归还给池子而非直接销毁它。这是一种特殊的工厂对象。
若初始化、实例化的代价高,且有需求需要经常实例化,但每次实例化的数量较少的情况下,使用对象池可以获得显著的效能提升。从池子中取得对象的时间是可预测的,但新建一个实例所需的时间是不确定。
另外,利用对象池,我们可以重用对象,减少对象的分配,对于垃圾回收的编程语言,也是一种提高性能的手段。
使用 SQL 的方式查询消息队列数据以及踩坑指南
为了让业务团队可以更好的跟踪自己消息的生产和消费状态,需要一个类似于表格视图的消息列表,用户可以直观的看到发送的消息;同时点击详情后也能查到消息的整个轨迹。
Python源码剖析:深度探索Cpython对象
Python是一门备受推崇的脚本语言,以其简单的语法和全面的功能而著称,可快速实现各种业务。本文从 CPython 对象构造器入手,介绍了浮点数对象在 CPython 底层数据结构中的表现形式以及对象创建的过程。通过进一步了解 CPython 动态性的实现方式,读者可望在阅读 CPython 源码后提升编写高质量代码的能力。
零拷贝技术第二篇:Go语言中的应用
书接上回:零拷贝技术第一篇:综述, 我们留了一个小尾巴,还没有介绍Go语言中零拷贝技术的应用,那么本文将带你了解Go标准库中零拷贝技术。
四舍五入在Go语言中为何如此困难
在 Go 语言中这似乎成为了难题,在 stackoverflow 上搜索 [go] Round 会存在大量相关提问,Go 1.10 开始才出现 math.Round 的身影,本以为 Round 的疑问就此结束,但是一看函数注释 Round returns the nearest integer, rounding half away from zero ,这是并不常用的 Round half away from zero 实现呀,说白了就是我们理解的 Round 阉割版,精度为 0 的 Round half up 实现,Round half away from zero 的存在是为了提供一种高效的通过二进制方法得结果,可以作为 Round 精度为 0 时的高效实现分支。
