原文

我收到抱怨,说很难使用arsd.archive的lzma解码器,所以做了个新接口.它好多了,我决定也为gzip做一样的.新函数如下:
gzip
lzma
(文档几乎相同,它们应该与相关项目相同,但显然我需要查看adrdox中有一个错误.但工作方式相同,因此交换算法与交换函数名一样简单,而不是像以前那样使用完全不同对象)

新函数通过闭包干活:要解压缩数据准备就绪时,它会调用你的块接收器,并在需要更多数据时调用你的缓冲填充器.然后,如果不喜欢默认值,可做一些配置.

我可能仍会更改它,以便块接收器可返回一个值,告诉它你已受够了,请尽早停止处理文件.但除此外,我对此很满意.它管理缓冲与对象.

一般,对象是外部驱动的,正确数据在正确的位置时,可调用它们的内部驱动函数,需要你在正确的位置放正确数据时,它们会调用你的函数.

外部驱动的可更灵活(尽管在缓冲填充器中有纤程提供大部分灵活性,但它有自己的问题),但内部驱动总是更容易使用.对这些,现在读取tar.gz或tar.xz很简单,因为这些函数可直接相互填充.

在此,从内存或文件中取数据来填充缓冲很简单,但从网络流中取可能有点困难.好吧,它不一定是,可做阻塞调用socket.receive,无论它填满多少缓冲,你返回函数,它都会利用它.所以用阻塞接收函数,它仍易于使用.

使用非阻塞函数呢,如何取就绪通知数据?这里外部驱动对象更好.但是,你可用纤程.

启动纤程并从那里调用解压缩函数.请求数据时,异步读取请求缓冲(或可中间缓冲流式传输,但如果大小适当,则一般直接更好),并产生(yield).

读完后,事件处理器调用纤程,然后它返回到解压缩程序并继续工作.它用外部驱动的数据源,及内部驱动API,代价是记住在纤程内部运行它.很好.

目录监听程序

我继续arsd.core工作,包括添加目录监听器类.我碰巧在周末打开了bsd框,所以我从基于kqueue的实现开始,然后,不爽.

我听说过很多关于kqueue的好东西,但直到最近我自己才使用它,虽然有一些我喜欢它的地方它的信号方案比Linux提供的要好,并且添加和等待组合还可(虽然它不像某些人说的那么好,但有时很高兴)但总之,我更喜欢Linux的epoll,timerfd,eventfd等方式.当然,窗口提供了许多不错的函数.

现在已用了一些kqueue,窗口的函数和Linux的inotify同样,Kqueue是其中令人失望的一个.你必须打开目录和目录自身中的每个文件,而窗口和Linux会从单个顶层告诉你更改了什么.
因此,支持kqueue系统对API设计有一些重大影响.我想带glob模式并在那扫描它们,也许在其他系统上搞个自动过滤器.

工具函数

arsd.core也在从其他模块中取分散工具函数并整合它们,并可编写一些小函数.
其中之一是flagsToString函数.这样:

en Flags {none = 0,a = 1,b = 2
}
assert(flagsToString!Flags(3) == "a | b");

主要是为了支持错误消息,其他地方也可能有用.

网络助手

我还开始从其他模块移植一些网络助手并统一接口.UDP监听器可安装每线程或任意线程回调.TCP监听器可自动分发连接给自己的工作线程.本地命名管道和unix套接字可用它或单独接口,来帮助处理单实例程序等.