d的arsd库的11版本
原文
亚当正在研究
我在arsd.core和WebSocket的实现上花了一些时间,websocket现在在它的onclose回调中提供了原因代码,arsd.core正式进入了repo,并开始积累一些功能.
在此有些文档
事件循环
core模块的核心特性是一个统一事件循环.有个满足所有模块的不同需求的实现,并不简单,但是一个统一接口也不是很差.
正在步进的是有四种可互操作事件循环的方法:
1,基于simpledisplay实现的UI循环.这是个通用循环,应该总是保持响应并优先考虑ui事件.
2,基于cgi实现的任务运行器.这是以i/o为中心的循环,如果需要,它可在任务上花费一些时间,但一般应该在响应新的请求时保持可用.自动分配传入任务.
3,基于terminal和http2实现合并的ad-hoc循环.这是线程执行其他工作时,期望随机进入和退出的通用循环.
4,助手工作者,它与任务运行器实现相同,但用法不同:运行不期望保持可靠响应的独立任务.
我还提交更改simpledisplay的窗口事件函数,以便在窗口平台上使用本地窗口消息,以帮助解决内部模态事件循环导致自定义事件处理停滞的一些问题.
Linux的实现已基本完成,正在实现窗口(大部分已在sdpy和cgi中了,但是适应新系统还需要一些工作).我读了与BSD/Mac实现相关的手册页,预计那里也不会有真实的的麻烦.
花了更多的时间考虑线程类型,但在决定开始行动后,看到与.net有一些重要的相似处时,给了我一些信心,该计划是不错的.
子进程通信
标准库的std.process对某些任务没问题,但是与子的交叉流通信有问题.这是想要解决的问题,也是个很好的事件循环实现的测试用例,所以实现了个外部过程类(ExternalProcess)及它的一些流适配器.
该外部过程类自身是相当普通的,它提供了从进程传入的stdout和stderr数据的回调,及向stdin发送某些内容的函数.但它引起事件循环中难搞的信号处理器问题.
我决定使用传统的自管道技巧,只是在Linux上使用eventfd而不是管道,因为除非你重置它,signalfd屏蔽会影响子进程,而且因为我不要求所有事情都经过我,可能不会重置.信号处理器已够糟糕的了,但至少这些不会在execs之间继承.它对流适配器提供了很好的测试用例.
流适配器用它证明了自己的能力,受unix管道的启发,一端接收原始字节数据,另一端按请求格式(如int,string,array等)输出数据,有一个流控制:如果消费者请求的数据不在缓冲中,可等待更多的数据.
在纤程中,这会产生(yield)直到喂了更多的数据.因此,这是种简单适配基于回调接口的外部过程转换成线性任务代码的方法."收到的数据"回调只需要调用stream.feedData(just_received)并再次触发该任务.
此时仍缺少外部进程的后压力.如果未使用流且缓冲已满,它应该停止从管道读,这会挂起产生数据的另一个进程,与缓冲为空时,挂起消费任务一样.当前实现假设你想读取所有数据;到达回调函数时,已从源管道中读取了它,且已发出更多数据请求.
我不得不在发布之前稍微调整一下设计来纠正该问题.最有可能的是,我创建显式请求更多数据的方法,而你在回调函数尾调用它,但其他地方也要求可调用它(如,发现缓冲不够时),因此不能只是传递给它.
还没有完全完成,但差不多了.
异常框架
早在2015年,我写了个叫做arsd.异常的模块,在此,来实现一些想法,不得不让异常更容易使用.模块工作了,但是好处不大.有了arsd.core,计算方法变化了,从而提供了实际使用这些概念的机会.
现在关键点是撤消D的基本正常异常中的一些反模式的基类,然后是两个平台相关错误的子类(从simpledisplay导入),及从参数生成新异常类的模板,以用在方便性和功能上都超过throw new Exception的替代方法.
关键目标是在方便使用的同时向上转发数据结构.开始使用后,目前部分成功.我会继续完善.
特别缺少某种多继承.如,根据调用函数,FileNotFound错误可能同时是FileNotFound异常和窗口Api异常或Errno异常.我想我会试按异常基础上的结构化成员公开标签,但我还不确定.
但即使我不能,仅附加基本信息就比普通异常和随机串好.
populateFromUda反射助手
arsd.core还包括一些包括(帮助异常框架的)intToString到更高级反射助手的通用帮助函数.
populateFromUda类似SS上次在dconf中谈到的"蓝打印"模式,我已在cgi.d和minigui.d中使用过.
Steve的演讲:幻灯片PDF|主视频|问答视频
好处是提供了记录可能uda及改善编译时间的锚.此外,也可从运行时数据填充结构,并可从文件加载,如接口设计者的gui输出.
放在核心中,更容易互操作,反射助手自身价值有限,但如CGI和minigui的实际共享类型可能更有用.针对Web或桌面演示重用某些表单成员.
arsd.core有个严格的无标准库策略,仅允许导入object和core.*名字空间.这是因为它是许多以前都是独立的其他模块的基础库.
因为一般在编译时,导入标准库非常昂贵,并且有时,编译器版本间不稳定,因此影响有时可能很大.
标准库错过了事件驱动.虽然它提供了消息传递,但没有实现全部潜力.有很多反射,但有成本.