@Rorysky
> Null checks are cheap. They usually fold straight into a related memory access instruction, and use the CPU bus logic to catch nulls. (Deoptimization follows, with regenerated code containing an explicit check.)

@Rorysky 信号量怎么就不是一个特性了？这都是写在文档上的，就因为它预期中不常见，所以就不是个特性从而可以随便更改了？既然承诺了它所产生的效果和副作用，怎么就不能用于优化了？实际上因为这个动作的延迟相对较高，JVM 的 JIT 也是用来做非预期分支去优化判定的。
一个东西既然承诺了效果，那就不该去干涉使用者怎么用，除非你有合理的理由，提前注明。

注意下 unexpected 不等于 undefined 也不等于 unspecified

@Rorysky 一大票设施利用这个段错误和总线错误信号来做兜底呢，这要是可以随便改大家程序都不要写了。好在这次水果只是改了一个特例而已。
预期外的行为，它也是良定义的，看看你引用的这句话的下一句。

不过这种破环兼容性的做法真是一言难尽

@codehz 还行，看了下只要他们切换下保护就没事了

> We discovered that if we switch the jit protection mode to EXEC rather than WRITE, then these page faults again raise the expected SIGBUS not a SIGKILL. Note the faulting accesses are predominantly reads and have nothing at all to do with accessing a MAP_JIT memory region.
> We have been working on a patch that switches the jit protection mode to EXEC around these potential faulting memory accesses. It has been a bit of an exercise in whack-a-mole finding them all, and testing is still in progress.

@codehz Go 写的程序可能也受影响，它的空指针访问也是可以在程序内部捕获的，而且好像也是通过段错误信号兜住的（只观察过 Linux/Windows 平台）

@rainbowmolly 触发段错误信号的行为是良定义+可保证的，如果能用来提升性能为啥不能用。你说的直接退出只是因为没有好好处理段错误信号吧。

这有点坑啊，这种重大变更怎么能无预警直接推呢，至少也应该保留一个逃生门。

远离 curd ，你看人家用 c cpp rust 写啥，你也写啥。现代 Java 基本都能做到，就是稍微麻烦点

另外如果可行，还是推荐使用现成可靠的地理信息设施，比如 PostGIS ，应该比 MySQL 自己的 GIS 功能强得多

以前流行过 geohash ，如果 MySQL 自己的地理信息功能挑不起来大梁，可以尝试附加一个 geohash

@CorgiDuu 是的，m3u8 和 ts 分片都是普通的文件，按文件分发处理就行，所以它才方便

此外给视频切片是个很重的工作

一般都是切好的，这样也利于缓存

我倒觉得还行，键盘用时间久了，我打字也不用摸 F J 上的凸起

@Nazz 确实，立刻还给了时间上的含有，也不合适…要不，“同步地返回”…得，循环了