Chinaunix

标题: libuv 是一个非常糟糕的, 垃圾透顶的库. [打印本页]

作者: 蔡万钊 时间: 2013-08-24 21:47
标题: libuv 是一个非常糟糕的, 垃圾透顶的库.
不得不说, libuv 是一个非常糟糕的, 垃圾透顶的库.

为啥这么说呢? 因为 uv_write 允许 NULL 回调! 鼓励忽略 write 的返回值! 鼓励编写面条代码, 垃圾代码就这样被 libuv 鼓励出来了.

uv_write 为啥允许 NULL 回调呢? 因为以前 libuv 的 uv_write 是没有回调也没有返回值的 , 你永远不知道发送成功了没. 后来大概作者意识到这个问题了, 就添加了回调....

然后估计是为了方便代码迁移吧, 允许 NULL 回调, 这样原来的代码加个 NULL 参数就继续工作了 ......

这写库是写着玩的吧?

作者: linux_c_py_php 时间: 2013-08-24 22:06
node.js才出来几天, 接口设计有问题也应该能接受.

作者: linux_c_py_php 时间: 2013-08-24 22:08
再说了, 为毛直接用libuv, 人家是为了做node.js, 顺便暴露个底层组件, 用libev,libevent才对.

作者: starwing83 时间: 2013-08-24 23:21
libev貌似最近有了Windows native的CPIO接口……

不过libuv因为有node.js当小白鼠，应该还是稳定一些。

话说回来，人家才0.10嘛，接口都没固定的，好歹等到1.0再说吧，说不准哪天就把NULL回调的特性给remove掉了= =

作者: 群雄逐鹿中原 时间: 2013-08-24 23:50
函数执行退出，数据可以不写完；数据写完，再执行回调。
他不就是要设计成回调吗？

作者: sxcong 时间: 2013-08-26 14:57
"允许 NULL 回调"是它设计的，感觉不合理可以不用，用的人肯定是有自己的目的。 node.js已经很多项目是实际使用了。
另外，比如delete 一个NULL指针，肯定要崩的, c++编译器可没管这个，该崩就崩，有意见吗？
libuv应该目前最简洁的网络库，libev只支持linux, libevent在windows下iocp还不完善，另外epoll效率也不够最优。至于boost,ace等，相信google和ms不会没听过这它们名字的，既然不用肯定也有道理（ms版的redis也在用libuv）。
连MS自己都在用，所以尽管放心就是了。
对google和ms里的程序员还是要有信心的。

作者: myworkstation 时间: 2013-08-26 16:27
回复 6# sxcong

C++明确规定delete一个null pointer没有任何影响，　Ｃ明确规定free一个null pointer不发生任何动作。所以无论C还是C++在删除空指针时的行为都是安全的。

作者: siseniao 时间: 2013-08-26 18:11
本帖最后由 siseniao 于 2013-08-26 18:13 编辑

讨厌回掉的当然选择NULL了，就像malloc一样，你会检查返回指针为空吗，我就从来不检查，如果连内存都分配不了，检不检查有毛区别，有时候貌似是正确的东西都是脱裤子放屁

作者: starwing83 时间: 2013-08-27 00:20
回复 8# siseniao

有种东西叫做紧急垃圾回收，所以还是检查一下好，恩

再不济，检查一下扔个异常（C++默认就是这个，所以C++不需要检查）或者直接abort都行啊，这样出问题了至少可以搞到core看看是不是哪里内存泄露了。

通常是可以不检查，不过，软件就是10%的代码90%情况在跑，90%的代码在处理10%的特殊情况的东西，所以，忍一忍吧= =

作者: siseniao 时间: 2013-08-27 09:02
回复 9# starwing83

碎片回收不应该是操作系统或者系统策略负责的吗，应用层不应该越权干这种事，至于内存泄露，检测分配内存值我认为对于找出内存泄露毫无帮助

作者: myworkstation 时间: 2013-08-27 10:08
回复 10# siseniao
这个问题要分两个层面去说，系统部分已经做了这个功能，但是系统毕竟不知道应用内部持有的内存哪些是必须的哪些是可以放弃的以及应用本身的内存分配粒度和策略都可以由应用本身最优化处理。内存池的意义也在于此。至于检查NULL指针的问题还是需要的（这是一个良好习惯），因为系统可能设置了quota，比如说许多web服务器会对cgi进程设置内存使用上限，这不是真的内存不够用，此时malloc依然会失败，这时程序不应试直接崩溃的。

作者: siseniao 时间: 2013-08-27 10:25
回复 11# myworkstation

不知道这个定额是如何实现的，如果仅仅是限制内存的话，即便你检查返回指针也是不能保证程序不崩溃的，举个例子，在函数里定义一个较大的内部变量

作者: myworkstation 时间: 2013-08-27 11:01
回复 12# siseniao

函数内较大的内部变量在放在stack上的，而malloc的内存是heap的。stack的大小在进程（线程）创建时就指定大小（默认10MB)。如果内部变量需要的大小大于这个值那么编译和运行应该都有问题需要（编译时需要指定选项）。无论如何如果stack的大小得不到满足那么进程根本启动不了会直接报错。而检查返回值处理的是heap的情况，两者并不矛盾。

作者: siseniao 时间: 2013-08-27 11:04

myworkstation 发表于 2013-08-27 11:01
回复 12# siseniao

函数内较大的内部变量在放在stack上的，而malloc的内存是heap的。stack的大小在进程 ...

你说的对，但是作为限制内存来说，我认为肯定是让程序实现内存计数比强制限定要合理得多

作者: myworkstation 时间: 2013-08-27 11:11
回复 14# siseniao

在多用户系统或类似的系统上强制限制资源使用肯定都是有效的方法，因系统本身的资源是有限的，比如说为每个用户设定其使用的资源配额。在不能修改用户程序时这是达到这个目标最合理的办法了。

作者: starwing83 时间: 2013-08-27 19:45
回复 10# siseniao

额……垃圾回收和碎片回收是两回事……而且碎片回收很多时候只能自己的程序干= =

不过检查malloc返回值的确是麻烦事儿

作者: jackarain 时间: 2013-09-05 06:10
回复 8# siseniao

write返回值的检查和malloc返回值，有本质的区别，你太不理解write和tcp了，多了解了解tcp，你就知道为什么write是必须检查并处理返回值的。

欢迎光临 Chinaunix (http://bbs.chinaunix.net/)