用过 skynet 的应该都碰到过:当我们在服务中不小心调用了一个长时间运行而不返回的 C 函数,会独占一个工作线程。同时,这个被阻塞的服务也无法处理新的消息。一旦这种情况发生,看似是无解的。我们通常认为,是设计问题导致了这种情况发生。skynet 的框架在监测到这种情况发生时,会输出 maybe in an endless loop 。
如果是 Lua 函数产生的死循环,可以通过发送 signal 打断正在运行运行的 Lua 虚拟机,但如果是陷入 C 函数中,只能事后追查 bug 了。
那么,如果我原本就预期一段 C 代码会运行很长时间,有没有可能从底层支持以非阻塞方式运行这段代码呢?即,在这段代码运行期间,该服务还可以接收并处理新的消息?
在上一篇文章[《聊聊来自元宇宙大厂 Meta 的相似度检索技术 Faiss》]中,我们有聊到如何快速入门向量检索技术,借助 Meta AI(Facebook Research)出品的 faiss 实现“最基础的文本内容相似度检索工具”,初步接触到了“语义检索”这种对于传统文本检索方式具备“降维打击”的新兴技术手段。有朋友在聊天中提到,希望能够聊点更具体的,比如基于向量技术实现的语义检索到底比传统文本检索强多少,以及是否有局限性,能不能和市场上大家熟悉的技术产品进行一个简单对比。那么,本篇文章就试着从这个角度来聊聊。
在 Go 1.19 的开发中, string.SliceHeader和string.StringHeader经历了一个生死存亡的争斗,这两个类型一度被标记为弃用(deprecated),但是这两个类型经常用在 slice of byte 和 string 高效互转的场景中,如果被标记为弃用,但是目前还没有可替代的方法,所以这两个类型又把弃用标记去掉了,如无意外,它们也会在 Go 1.20 再次被标记为弃用。