惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

月光博客
月光博客
Martin Fowler
Martin Fowler
Last Week in AI
Last Week in AI
罗磊的独立博客
阮一峰的网络日志
阮一峰的网络日志
博客园 - 【当耐特】
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
博客园 - 三生石上(FineUI控件)
S
SegmentFault 最新的问题
V
Visual Studio Blog
Hugging Face - Blog
Hugging Face - Blog
雷峰网
雷峰网
博客园_首页
人人都是产品经理
人人都是产品经理
量子位
美团技术团队
The Cloudflare Blog
小众软件
小众软件
WordPress大学
WordPress大学
有赞技术团队
有赞技术团队
M
MIT News - Artificial intelligence
Microsoft Security Blog
Microsoft Security Blog
D
DataBreaches.Net
博客园 - Franky

Solaris

请问有人做过 sun 服务器的虚拟化吗 最新的Solaris 11.1 X86是什么授权了?
这两天为 libhv 做了 Solaris 的适配,两点小感受
CismonX · 2020-05-06 · via Solaris

第一点,Solaris 的 event ports API 设计的可谓是非常简洁优雅了,用起来很舒服,一气呵成。不像之前用 kqueue 的时候,各种踩坑。

第二点,C 语言项目中的一大问题就是对全局命名空间的污染。在为 libhv 适配 Solaris 的时候,发现项目作者对命名不是非常讲究,导致与一些系统 API 命名冲突。比如 sockaddr_un,比如 gethrtime()。当这样的问题出现在库中时,有时会让用户很头疼,因为命名随意很有可能导致它们与其他的库也可能会有冲突。

所以我在自己的 C 项目中,一般是这样做的:

  1. 暴露给调用方的头文件中,所有的定义与声明(包括宏定义)都用项目名(或者其缩写)作为前缀,如 libxxx_do_something()LIBXXX_MAX_FOO_SIZE
  2. 永远不 typedef struct/union/enum 。

附 PR 链接: https://github.com/ithewei/libhv/pull/4