About skywind3000

Rust 并不适合开发游戏，它更擅长有明确定义，边界清晰的项目，这样你类型体操一遍做完问题不大，比如重构个已经十年没变过的 C 模块，但游戏领域并没有明确的定义，策划案不停修改，你的代码不但要求快速迭代还要求不停重构，那么类型体操在这过程中就变成锁死你的紧箍咒。

参考文章：3 年写了 10 万行代码开发者吐槽：当初用 Rust 是被忽悠了

这里解释一下，为什么当项目没有明确定义时，rust 为啥会显得笨拙？因为此时不但需求会随时间变来变去，更要命的是你没有一份十年没变过的 C 代码做参考，对项目整体实现缺乏全局的认识，只有自底向上的方法不断尝试和修正自己，不段反思和改进中上层代码，才能像盲人摸象那样逐步认清楚整个世界因该是啥样。

而此时类型体操会在这时勒得你喘不过气来，一个之前需要横着用的变量现在需要竖着用了，你思来想去发现你完全没办像其他语言那样改成法竖着用了，于是你只有引入更大范围的重写才能解决问题，你觉得这样很难受，去 rust 社区寻求帮助，但发现他们并不会帮助你真的解决语言问题，只会一个劲的指责你 “你觉得痛苦正是因为你对 rust 不熟悉导致的” 或者 “rust 逼迫你更大范围重写正是逼你尽早写出更好的代码”，他们这么说在定义清晰的项目里的确没问题，越早重构越好，但在定义不清晰的项目上里存在大量中间设计，你今天改成这样，八成不是最终形态，隔几天可能还要改，而此时 rust 却逼迫你每次都提前费精力进行更大范围的重写，即使这时完全没必要的，过两天就不需要的，他也不许你像其他语言那样用快速实现的方式应对新的中间状态，等需求稳定了，技术方案也收敛的情况下再进行迭代和完善，然后你就抓狂了！

网友 FENG DONG：项目没有明确定义时候，需要设计 cost function，然后让代码沿着 gradient 演进。但 Rust 不是一种可微的语言。

网友 Aaltonen：游戏开发是 “巨型可变状态球” （giant balls of mutable state），需求像 gradient descent 一样逐步演进，但 Rust 的借用检查器（borrow checker）和所有权模型强制你 “一次性想好”，导致小改动引发大重构。

那么 Rust 适合开发游戏引擎么？我只能说 depends，主要到了现在也没啥 rust 开发游戏引擎的成功例子啊，一天到晚到处搞营销的 rust 游戏引擎 bevy 基本上类似个玩具，到现在都没啥靠谱的商业游戏案例，顶多几个独立小游戏之类，而且它要求用 rust 来写业务逻辑，这个上面已经论述过，它并不适合开发游戏业务逻辑；

Continue reading→

我的博客使用的 wordpress 一直架设在 bluehost.cn 上，差不多十多年了，前两天突然就不能访问了，后台也登录不进去，一查 bluehost.cn 主页，原来停止服务了，很多和我一样在上面运营十多年的网站都是说停就停，然后完全不提供数据备份的时间，连个电话都不给你打一个，就是邮件垃圾箱里提前几天给你发了一封告知邮件，人家 linode 之类的欠费停止你服务后，任然给你机会备份走，结果它完全不给。

所以没有啥完全稳定会一直存在的服务商，幸亏我机器上有备份，调查了以下几家虚拟主机提供商，他们的业务发展情况及稳定性，最后迁移 bluehost.com 了，帖子和评论都恢复了，但是页面访问统计没恢复到，因为页面访问统计插件是把数据存在别的 mysql 表里的，但之前用的备份插件又是只导出 wordpress 标准表格，所以包括访问统计，upvote 之类的数据全部清零了，无所谓了，还好访问量不算啥重要的东西，希望这次 bluehost.com 能多用两年。

之前我用过 bluehost.com 的，指示图 bluehost.cn 服务器在香港，国内访问会快点后面才选他，看来太小众的还是有问题。这次 bluehost.com 的服务器在亚利桑那，虽然远点，但国内访问起来，只要不下载，看个页面什么的也还算顺利。

有人问我为何不用静态页面？发布到 github pages 上那种，因为我这个 wordpress 博客以及个人 wiki 只依赖一家服务商，但是 github pages 页面需要依赖 github，评论需要依赖 gihtub issues+插件，计数器又需要依赖别的什么服务，依赖的服务太多了，上网那么多年我从不相信有什么服务可以一直持续下去的，所以依赖自然也少越好。

除了服务外，依赖的项目也是越少越好，之前那些 github pages 使用的基于 issues 的插件突然作妖，要收费，不收费就给你插广告，闹得天怒人怨，你还没办法，历史评论是博客相当重要的数据，依赖 github issues 作为评论数据存储的机制还有个致命方案是你还不能方便的导入导出，你会被绑死在 github issues 这个方案上，完全无法掌握自己的数据，不说 github 停止服务，一旦它一朝更改 api 规则（跟 twitter 一样）就只有哭了。

最后 wordpress 的功能真的很强大，插件生态也非常丰富，我也比较熟悉，有啥需求大概都能搞得定。

不怕不识货，就怕货比货，以下七点帮你了解差距究竟有多大：

第一：微信桌面 Qt 版引用了来自 Telegram 的 GPL 代码，对二进制 grep 一下字符串 desktop-app 就可以看到。有人找相关负责人提了一年了，结果连删掉字符串都懒得删。

第二：微信这么喜欢抄 Telegram 却不多抄点好的，比如微信群历史服务器只能保存两周，图片更短，当时没下载的图片几天后想看看就发现被服务器清除了，而 tg 全球十亿用户，消息存服务器四五年都不会删；

第三：什么年代了，微信附件大小最大 100M（不知改了没？）tg 随便存 10G 附件，一存好几年！一年前群里存的视频现在都找的到；

第四：微信那么挣钱的产品，结果给你搞个朋友圈合照都看不清脸的究极图片压缩，号称节省存储空间，好意思么？语音质量被压缩的经常听不清楚，飞书和钉钉的语音都比它清晰一万倍；

第五：微信用起来比 Telegram 卡有很多原因，其中一个重要原因就是微信使用单消息队列，所有消息挤压在一起，每次切换到微信就要同步一半天，包括全局消息和每个群最近的几百条消息，必须要同步完才能近一步操作，几秒时间消息列表不断更新跳变，点击无响应，导致想发给老婆的话明明点了老婆头像，最后因为列表跳变发到了同事群或者小孩班级群里去了，闹出了无穷无尽的笑话；但 Telegram 之所以不卡一个重要设计就是消息使用多队列，同时不需要等消息同步完才能操作，多个消息队列可以一边同步一边操作，每次切换过去你都可以立即流畅的操作，各个群的最近消息历史会使用并行的多个消息队列在后台并行同步，根本不影响你操作；

Continue reading→

我小学时用的 GMT-92 学习机写程序，就是 FC 6502 那一套，但比后辈小霸王强多了：右上方有磁带盒，有很多扩展软件以磁带形式发布，自己写的 BASIC 程序也可以录制到磁带上下次接着写，小霸王那种没有存储设备一关机你的代码就没有的环境是根本没法学习编程的，因为代码完全无法积累，每次重来，你永远写不了复杂的软件，而这台 GMT-92 最核心的地方就是提供磁带存储，让我可以写稍微复杂点的代码，我就抱着一本 BASIC 说明书开始抄写上面的各种例子代码，然后修改部分不停验证学编程的:

那时我想做一个空战游戏，但是我只会每次循环控制一个飞机从左边移动到右边，完全不知道该如何同时控制多架飞机，因为身边没人教，没网络，书店里没游戏开发书籍，也没处问人，只能去书店看相关的电脑书籍得知有些操作系统是有多任务功能的，可以同时运行几段程序，我心想这就是我想要的，可 GMT 根本没有多任务这个功能怎么办呢？

Continue reading→

最近 raylib 比较火，又是移植 web 又是移植掌机，看了眼 raylib 的例子代码，知道它为什么代码量那么少了，它甚至连一个显示对象树/场景树都没有实现，就是直接调用各种 draw 函数，和 ImGUI 一样属于 “立即模式”，这种模式做点简单的东西很舒服，对象一多一复杂就会比较麻烦：

那么这种每帧控制自己绘制的立即模式有啥问题呢？

Continue reading→

说实话，编译器是否该利用 Undefined Behavior 进行优化目前都还是一个争议话题，主要是 gcc 开了个坏头，不予余力的在默认参数下利用 UB 来优化，举个例子，C 语言里带符号整数溢出是未定义行为，编译器应该假设它实际上以某种方式定义了：

int foo(unsigned char c) {    int value = 2147483600;    value += c;    if (value < 2147483600)         bar();    return value;}

但利用这个 UB 进行优化的编译器会认为，既然 x 不会是负数，那么 value < 2147483600 就永远不会发生，所以整个 if 语句以及后面的 bar() 调用将可以被忽略，变成：

int foo(unsigned char c) {    int value = 2147483600;    value += c;    return value;}

这其实是一种很危险的做法，因为 C 语言可以跨越各种 CPU 架构编程，当年标准定义时，CPU 架构的差异比今天还大，在处理上面这类问题时，即便在今天，不同的架构结果并不一定相同，比如有的平台用补码表示负数，所以溢出了就会变成 -2147483648，而碰到反码或者原码表示负数的架构下，溢出了可能就变成 0 或者其它，所以一些事情根本就没法具体定义，必须留给具体编译器具体平台去处理。

Undefined Behavior 并不是说代码这么写是错的，相反他们都是语法正确的代码，真是错的应该就编译错误了，而是标准留个编译器实现者以自由，不去做限制，让他们根据实际平台，根据自己实现情况自行选择实现方式，而某些编译器实现选择利用它来进行优化了，那么如果本来就想利用特定平台的特性完成某些特定功能时，所以这类代码将没法写了。

关于这个问题，有个 X 友说的很准确，这里贴下译文（原文贴后面）：

亲爱的 C 程序员们，既然你们似乎无法阅读关于你们编程语言的文档，让我为你们解释一下什么是未定义行为，更重要的是它不是什么。

引用 C 标准：

未定义行为：本国际标准未做任何强制要求的行为。（Undefined behavior: behavior for which this International Standard imposes no requirements）

这意味着标准并没有规定某些表达式该如何表现，编译器的创造者们可以自由选择他们想要的行为，例如：

• 使编译失败
• 删除有问题的表达式并继续编译
• 发送给你的前任一条“我想你了”的消息
• 将你的票投给一个 XX 主义政党
• 甚至定义该行为（以平台特定的方式或非特定方式）

即，编译器的职责是合理处理未定义行为的情况。C 标准并没有对编译器作者提出挑战，这不是 “尽情发挥，给我惊喜”，它仅仅是对某些表达式没有施加限制，因为给予编译器作者自由选择其解决方案是合情合理的，因为这可能依赖于平台。

未定义行为并不是关于“被禁止的表达式”，它仅仅是语法上正确的 C 代码，而 C 标准对此并不关心。

到目前为止，这一切都是合理的。

在处理未定义行为时，编译器作者有多种选择：

• 偏向一致的语义
• 偏向性能
• 偏向实现的简单性
• …

正确的答案总是 “默认优先语义而非性能”。可以有破坏语义的优化，但这些优化应该通过适当的编译选项来启用，以便那些知道自己在做什么的人（或至少在继续破坏代码之前，编译器会得到明确的同意）使用。

（点击 more/continue 继续阅读）

Continue reading→

异步事件模型中有一个重要问题是，当你的 select/poll 循环陷入等待时，没有办法被另外一个线程被唤醒，这导致了一系列问题：

1）在没有 pselect/ppoll 的系统上，信号无法中断 select/poll 等待，得不到即时处理；
2）另一个线程投递过来的消息，由于 select/poll 等待，无法得到即时处理；
3）调短 select/poll 的超时时间也无济于事，poll 的超时精度最低 1ms，粗糙的程序可能影响不大，但精细的程序却很难接受这个超时；
4）有的系统上即便你传了 1ms 进去，可能会等待出 15ms 也很正常。

比如主线程告诉网络线程要发送一个数据，网络线程还在 select/poll 那里空等待，根本没有机会知道自己自己的消息队列里来了新消息；或者多个 select/poll 循环放在不同线程里，当一个 accept 了一个新连接想转移给另一个时，没有办法通知另一个醒来即时处理。

解决这个问题的方法就叫做 self-pipe trick，顾名思义，就是创建一个匿名管道，或者 socketpair，把它加入 select/poll 中，然后另外一个线程想要唤醒它的话，就是往这个管道或者 socketpair 里写一个字节就行了。

类似 java 的 nio 里的 selector 里面的notify() 函数，允许其他线程调用这个函数来唤醒等待中的一个 selector。

具体实现有几点要注意，首先是使用notify() 唤醒，不用每次调用notify() 都往管道/socketpair 里写一个字节，可以加锁检测，没写过才写，写过就不用写了：

// notify select/poll to wake upvoid poller_notify(CPoller *poller) {    IMUTEX_LOCK(&poller->lock_pipe);    if (poller->pipe_written == 0) {        char dummy = 1;        int hr = 0;    #ifdef __unix        hr = write(poller->pipe_writer_fd, &dummy, 1);    #else        hr = send(poller->pipe_writer_fd, &dummy, 1);    #endif        if (hr == 1) {            poller->pipe_written = 1;        }    }    IMUTEX_UNLOCK(&poller->lock_pipe);}

大概类似这样，在非 Windows 下面把pipe() 创建的两个管道中的其中一个放到 select/poll 中，所以用write()，而 Windows 下的 select 不支持放入管道，只支持套接字，所以把两个相互连接的套接字里其中一个放入 select。

两个配对的管道命名为 reader/writer，加入 select 的是 reader，而唤醒时是向 writer 写一个字节，并且判断，如果写过就不再写了，避免不停 notify 导致管道爆掉，阻塞线程。

而作为网络线程的 select/poll 等待，每次被唤醒时，甭管有没有网络数据，都去做一次管道复位：

static void poller_pipe_reset(CPoller *poller) {    IMUTEX_LOCK(&poller->lock_pipe);    if (poller->pipe_written != 0) {        char dummy = 0;        int hr;    #if __unix        hr = read(poller->pipe_reader_fd, &dummy, 1);    #else        hr = recv(poller->pipe_reader_fd, &dummy, 1);    #endif        if (hr == 1) {            poller->pipe_written = 0        }    }    IMUTEX_UNLOCK(&poller->lock_pipe);}

每次 select/poll 醒来，都调用一下这个poller_pipe_reset()，这样确保管道里的数据被清空后，就可以复位pipe_written 标志了。

让后紧接着，处理完所有网络事件，就检查自己内部应用层的消息队列是否有其他消息投递过来，再去处理这些事件去；而其他线程想给这个线程发消息，也很简单，消息队列里塞一条，然后调用一下notify()，把该线程唤醒，让他可以马上去检查自己的消息队列。

主循环大概这样：

while (is_running) {    // 1）调用 select/poll 等待网络事件，超时设置成 1ms-10ms；    // 2）醒来后先处理所有网络事件；    // 3）如果和上次等待之间超过 1毫秒，则马上处理所有时钟超时事件；    // 4）检查自己消息队列，并处理新到来的事件。}

差不多就是这样。

PS：有人说用 eventfd 也能实现类似效果，没错，但不能跨平台，只有 Linux 特有，而且还有一些坑，但 self-pipe trick 是跨平台的通用解决方案，不管你用 Windows / FreeBSD / Linux / Solaris 都可以使用这个功能。

在 Linux/Unix 等 posix 环境中，每个套接字都是一个文件描述符fd，类型是int，使用起来非常方便；但在 Win32 环境中是SOCKET 类型被定义成UINT_PTR ，是一个指针，在 x64 环境中一个SOCKET 占用 8 个字节。

那么是否能将SOCKET 类型强制转换成int 类型保存没？这样就能统一用int 在所有平台下表示套接字了，同时在 x64 环境下这样将 64 位的指针转换为 32 位的整数是否安全？

答案是可以的，下面将从三个方面说明一下。

Kernel Object

每个 SOCKET 背后其实都是一个指向 Kernel Object 的 Handle，而每个进程的 Handle 的数量是有限的，见 MSDN 的Kernel Objects：

Kernel object handles are process specific. That is, a process must either create the object or open an existing object to obtain a kernel object handle. The per-process limit on kernel handles is 2^24. However, handles are stored in the paged pool, so the actual number of handles you can create is based on available memory.

单进程不会超过 2^24 个，每个 Kernel Object 需要通过一个 Handle 来访问：

这些 Handle 保存于每个进程内位于低端地址空间的 Handle Table 表格，而这个 Handle Table 是连续的，见 MSDN 中的Handles and objects：

Each handle has an entry in an internally maintained table. Those entries contain the addresses of the resources, and the means to identify the resource type.

这个 Handle Table 表格对用户进程只读，对内核是可读写，在进程结束时，操作系统会扫描整个表格，给每个有效 Handle 背后指向的 Kernel Object 解引用，来做资源回收。

所以看似是UINT_PTR 指针的SOCKET 类型，其实也只是一个表格索引而已，这个 Handle Table 表格的项目有数量限的（最多 2^24 个元素），内容又是连续的，那当然可以用int 来保存。

开源案例

故此不少开源项目也会选择在 Windows 环境下将SOCKET 类型直接用int 来存储，比如著名的 openssl 在include/internal/sockets.h 里有解释：

/* * Even though sizeof(SOCKET) is 8, it's safe to cast it to int, because * the value constitutes an index in per-process table of limited size * and not a real pointer. And we also depend on fact that all processors * Windows run on happen to be two's-complement, which allows to * interchange INVALID_SOCKET and -1. */#   define socket(d,t,p)   ((int)socket(d,t,p))#   define accept(s,f,l)   ((int)accept(s,f,l))

所以 openssl 不论什么平台，都将套接字看作int 来使用：

int SSL_set_fd(SSL *ssl, int fd);int SSL_set_rfd(SSL *ssl, int fd);int SSL_set_wfd(SSL *ssl, int fd);

所以它的这些 API 设计，清一色的int 类型。

程序验证

道理前面都讲完了，下面写个程序验证一下：

Continue reading→

在做跨平台网络编程时，Windows 下面能够对应 epoll/kevent 这类 reactor 事件模型的 API 只有一个 select，但是却有数量限制，一次传入 select 的 socket 数量不能超过FD_SETSIZE 个，而这个值是 64。

所以 java 里的 nio 的 select 在 Windows 也有同样的数量限制，很多移植 Windows 的服务程序，用了 reactor 模型的大多有这样一个限制，让人觉得 Windows 下的服务程序性能很弱。

那么这个数量限制对开发一个高并发的服务器显然是不够的，我们是否有办法突破这个限制呢？而 cygwin 这类用 Win32 API 模拟 posix API 的系统，又是如何模拟不受限制的 poll 调用呢？

当然可以，大概有三个方法让你绕过 64 个套接字的限制。

方法1：重定义 FD_SETSIZE

首先可以看 MSDN 中 winsock2 的select 帮助，这个FD_SETSIZE 是可以自定义的：

Four macros are defined in the header file Winsock2.h for manipulating and checking the descriptor sets. The variable FD_SETSIZE determines the maximum number of descriptors in a set. (The default value of FD_SETSIZE is 64, which can be modified by defining FD_SETSIZE to another value before including Winsock2.h.)

而在winsock2.h 中，可以看到这个值也是允许预先定义的：

#ifndef FD_SETSIZE#define FD_SETSIZE 64#endif

只要你在 include 这个winsock2.h 之前，自定义了FD_SETSIZE，即可突破 64 的限制，比如在 cygwin 的 poll 实现poll.cc，开头就重定义了FD_SETSIZE：

#define FD_SETSIZE 16384        // lots of fds#include "winsup.h"#include <sys/poll.h>#include <sys/param.h>

定义到了一个非常大的 16384，最多 16K 个套接字一起 select，然后 cygwin 后面继续用 select 来实现 posix 中 poll 函数的模拟。

这个方法问题不大，但有两个限制，第一是到底该定义多大的FD_SETSIZE 呢？定义大了废内存，每次 select 临时分配又一地内存碎片，定义少了又不够用；其次是程序不够 portable，头文件哪天忘记了换下顺序，或者代码拷贝到其它地方就没法运行。

因此我们有了更通用的方法2。

（点击 more/continue 继续）

Continue reading→

二十多年前的某一天，我盯着资源管理器里很久没用却一直舍不得删除的 UCDOS 文件夹犹豫了半天，最终却为了给硬盘腾点空间一狠心 shift+delete 把他们彻底删除了，当时我没意识到，一个时代就这样彻底的离我远去；二十多年后的今天，我又在最新版的 DOSBOX 里把这些当年的工具一个个重新装了回去，软件没变，但是消逝的青春却再也回不来了。

做了一个《上古软件仓》，包含上古时代的编程工具，汉字系统和设计软件等，都是一些我以前经常用的软件，主打怀旧和娱乐。

截图：中文系统

（点击 more/continue 继续）

Continue reading→