Chinaunix首页 | 论坛 | 博客
  • 博客访问: 88826
  • 博文数量: 31
  • 博客积分: 2010
  • 博客等级: 大尉
  • 技术积分: 350
  • 用 户 组: 普通用户
  • 注册时间: 2007-10-16 20:38
文章分类
文章存档

2009年(12)

2008年(19)

我的朋友

分类:

2008-09-04 23:46:00

相信很多朋友都知道“pool”的概念,比如说thread pool,memory pool等等,关于这些东西,我在这里的论坛上看到已经很多相关的讨论,因此也就不去详述如何去design和implement,而且很多thread pool的源码随处都能下载,因此再讲也没有太大意义了。

那么,“pool”这个东西究竟有什么好处呢?这个得从“pool”的本质来谈。其实,“pool”可以实现资源的集中式管理。集中式资源管理的好处在于其他的业务逻辑可以不用再考虑如何获取资源和释放资源,在实现时可以将精力focus在要实现的业务逻辑上。当然,集中式资源管理还帮助实现软件的模块化,并且,由于资源是集中在一起被管理,因此如果在资源管理上存在bug,那么开发人员可以比较容易地fix掉。

然而,不会因为有了集中式资源管理,软件就不会出错,因为我们知道runtime error是无法避免的,正因为无法避免,因此才会有异常处理机制。那么runtime error出错之后,我们能做些什么呢?我想这个得根据error的level来确定如何去处理。一旦发生critical的error,那程序必须立刻退出,因为不退出的话,也许后续会有更critical的error,这时可能会发生disk data corruption这样没人愿意看到的实情,所以这时必须立即退出。但是,有的错误,却允许我们去retry,比如说当我们调用Linux read的时候得到errno==EINTR的结果,这个时候我们清空buffer中已有的内容,重新开始read。也就是说,error不同,那么处理的方式也会跟着变。那这个时候就有些麻烦了,因为我们知道error的处理是分布在整个系统的各个模块中,一旦我们决定说某个error的处理方式需要改动,那么我们就要遍历整个系统的source code来寻找这个error,然后更新这个error的处理方式。如果error的处理方式需要结合上下文来决定,那情况就更复杂了!

于是我们想能不能将error也集中起来管理呢?然而,这似乎不太可能做到!因此,我们只能退而求其次,将所有的敏感信息记录在log中,这样我们也能在发生错误的时候根据log中的上下文来诊断错误的根源!
阅读(549) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~