qkc开发总结

qkc库是windows下的libc库,兼容posix标准,并实现linux下特有的API接口。它可以被visual studio直接使用,用来编译linux下的c源码。经过半年的开发,基本完成代码总体框架,还没有经过调试验证,也算告一段落。qkc的实现参考了glibc/linux/cygwin以及网络上的许多博客,感谢这些源码的作者。

在windows和linux的底层API中,功能上基本相似,但在细节处中有诸多不同,为了完全兼容,除了需要在性能上容忍损失,还是有不少难点。

1、难度最大的是跨进程通讯。Linux下的跨进程通讯方式,windows都有对应的接口,共享内存,信号量,互斥量。不同的是,linux是以一个整型变量来标识,而windows是以字符串来标识,导致这需要一个映射管理器来管理这个对应关系。一个取巧的办法是,让这些字符串按照prefix + id的格式拼接而成,就可以省去管理。

linux下当进程退出时,会自动释放这些资源。但是qkc因为是用户层的库,在系统API上做了一层封装。当windows退出时,会自动释放系统资源,不会自动释放qkc为封装而申请的资源。其他进程也无法感知该进程的退出,如果此时在竞争一个锁,就可能导致死锁。

2、文件系统。在linux下一切皆文件,比如跨进程通讯的/dev/shm,比如管理进程的/proc。在windows下,提供普通文件的接口,这些信息涉及到全系统公共信息,只有一个动态库中难以模拟。这个问题,其实和跨进程通讯类似,需要有个全局性的管理器。

3、epoll的实现。和epoll对应的是IOCP,但是epoll模型是reactor模式,而IOCP是preactor模式。这个模拟方法在《epoll移植到windows的可能性》中提到。与此类似的,还有inotify。inotify的难点同时也和文件系统相关,/proc/sys/fs/inotify其实也是一个虚拟文件系统。

4、syscall,syscall的实现并没有特别的难度,关键是量大,有几百个。

5、errno和GetLastError的对应关系,和syscall一样,量大而且还不能完全匹配。

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180530G0O16200?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。

同媒体快讯

扫码关注云+社区

领取腾讯云代金券