- 主题:关于FB2000使用DLM的问题
【 在 flyriver (忧郁的飞流直下) 的大作中提到: 】
: 是这样的，原来的 FB 系统是把所有的功能都做到一个文件里面，即 bbsd。
: 后来 FB2K 做了一点改动，把系统维护菜单的所有功能单独编译成 admintool.so，
: 于是 bbsd 也小了一些。
: 设原来的 bbsd 为 bbsd1, 新的小一些的 bbsd 为 bbsd2。
: bbsd2 + admintool.so >= bbsd1 ?
: 原来的 100 个进程 100 * bbsd1，
: 新的为 95 * bbsd2 + 5 * (bbsd2 + admintool.so)，
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
这里不对吧，应该是100 * bbsd2 + 1 * admintool.so吧
这个.so最后就一份在内存中啊
: 那么这两个哪个大，哪个小呢？
: 【 在 scz (小四) 的大作中提到: 】
: : 如果是同一个.so，dlopen()多少次都一样啊
: .................（以下省略）
--
FROM 166.111.168.8
【 在 quickmouse (碰猫死翘翘) 的大作中提到: 】
: 我想flyriver和我是一个意思，比如：
: 大部分用户使用的bbsd进程只有普通的功能，如阅读文章等等，
: 但是单独的一些管理功能以及特殊功能放在一个.so当中，仅仅
: 在部分用户使用过程当中才调用，是不是可以认为：
: 原来不使用DLM的bbsd集成了所有的功能，其大小大于普通功能的
: bbsd。虽然加上特殊功能.so后会比集成所有功能的bbsd要大，但大
: 部分的用户很少使用特殊功能。
: 这样可以达到所有在线用户占用的内存总量减小的效果？
这个啊，这个我倒是觉得可以节省下来，我前面说不能节省内存，
不是说这个地方，我是针对那个dlopen() vs. ld的来说的
: 【 在 scz (小四) 的大作中提到: 】
: .................（以下省略）
--
FROM 166.111.168.8
【 在 flyriver.bbs@apue.dhs.org (忧郁的飞流直下) 的大作中提到: 】
: 是这样的，原来的 FB 系统是把所有的功能都做到一个文件里面，即 bbsd。
: 后来 FB2K 做了一点改动，把系统维护菜单的所有功能单独编译成 admintool.so，
还有: 其实偶觉得DLM是从FB3.0里面移植过来的. 因为最早采用DLM的就是
FB3.0-20000220-SNAP, 从ChangeLog可以看出来.FB2k的ChangeLog
里面提到DLM是在20000508-pre, DLM这个idea应该是台湾那边的原创.
: 于是 bbsd 也小了一些。
: 设原来的 bbsd 为 bbsd1, 新的小一些的 bbsd 为 bbsd2。
: bbsd2 + admintool.so >= bbsd1 ?
: 原来的 100 个进程 100 * bbsd1，
: 新的为 95 * bbsd2 + 5 * (bbsd2 + admintool.so)，
: 那么这两个哪个大，哪个小呢？
--
FROM 166.111.60.178
看了你和KCN的文章，我倒是犯糊涂了，按KCN的说法，所有的代码正文段
都是share的，.so按你说的也是share的，如果说在.so当中基本上都是
自动变量或者malloc等内存分配，那岂不是无论如何DLM都没有优势？
毕竟从一个大站来考虑，所有的用户在同一时间使用上会覆盖所有功能。 :(
【 在 scz (小四) 的大作中提到: 】
: 【 在 quickmouse (碰猫死翘翘) 的大作中提到: 】
: : 我想flyriver和我是一个意思，比如：
: : 大部分用户使用的bbsd进程只有普通的功能，如阅读文章等等，
: : 但是单独的一些管理功能以及特殊功能放在一个.so当中，仅仅
: : 在部分用户使用过程当中才调用，是不是可以认为：
: : 原来不使用DLM的bbsd集成了所有的功能，其大小大于普通功能的
: : bbsd。虽然加上特殊功能.so后会比集成所有功能的bbsd要大，但大
: : 部分的用户很少使用特殊功能。
: : 这样可以达到所有在线用户占用的内存总量减小的效果？
: 这个啊，这个我倒是觉得可以节省下来，我前面说不能节省内存，
: .................（以下省略）
--
FROM 211.69.197.73
【 在 KCN (毒中之毒~生亦何欢，死亦何苦) 的大作中提到: 】
: 100 * bbsd1 = bbsd1 无论多少个进程在内存中都只有一个程序副本
: 95 * bbsd2 + 5* (bbsd2 + admintool.so) = bbsd2 + admintool.so
: 一般来说，第二个大，但是如果写得不好的.so使用了大量静态内存的除外。
而且 DLM 里面如果在栈里分配了大量内存，即使卸载 .so ,那些内存还是不
被释放, 因此千万不要图省事狂开大临时变量
--
FROM 166.111.164.206
【 在 period (瞌睡虫soso) 的大作中提到: 】
: 还有: 其实偶觉得DLM是从FB3.0里面移植过来的. 因为最早采用DLM的就是
: FB3.0-20000220-SNAP, 从ChangeLog可以看出来.FB2k的ChangeLog
: 里面提到DLM是在20000508-pre, DLM这个idea应该是台湾那边的原创.
其实 FB 3.0 里面的很多东西也是从 Maple 3 里面来的
M3 在台湾的发展远先进于 FB3
--
FROM 166.111.164.206
【 在 quickmouse (碰猫死翘翘) 的大作中提到: 】
: 看了你和KCN的文章，我倒是犯糊涂了，按KCN的说法，所有的代码正文段
: 都是share的，.so按你说的也是share的，如果说在.so当中基本上都是
我的意思是.so的代码段部分以及所有只读部分是共享的
可写部分当发生copy on write时就不是共享的了
所以如果这个.so中有大量copy on write情形，那不用也罢
: 自动变量或者malloc等内存分配，那岂不是无论如何DLM都没有优势？
: 毕竟从一个大站来考虑，所有的用户在同一时间使用上会覆盖所有功能。 :(
: 【 在 scz (小四) 的大作中提到: 】
: : 这个啊，这个我倒是觉得可以节省下来，我前面说不能节省内存，
: : .................（以下省略）
--
FROM 166.111.168.8
【 在 quickmouse.bbs@apue.dhs.org (碰猫死翘翘) 的大作中提到: 】
: 鉴于要整理fb2k的代码，这个问题想弄清楚一些。小弟原来接触
: 的程序是fb2kv1219(beta4)，这个版本的fb2k是没有DLM的版本，当然
: 也就没有游戏。在其附近使用DLM的版本有v1126和v1.0909(v1.0423)。
: 据老农的论文分析，使用DLM是为了节省每一个用户所占用的系统
: 资源，当某些功能仅被少数用户使用的时候较有优势，但代码调用较慢。
: 另一方面，据说（仅仅是据说，请大家验证）DLM在某些系统上运转
: 有问题。当然DLM的一个好处是可以把很多扩展功能做出来，甚至可以
: 把原来一些由crontab完成的工作整合进来，达到统一。
: 我想听听大家的意见，是否把DLM整合到整理的版本中来，如果这样
: 某些功能可能需要调整到不同的文件当中了，谢谢！
我觉得把用的少的功能做成"bbsnet"类的外部执行的程序比较好,这样可以简化
bbsd的代码,你即使是使用了DLM,bbsd里还是会留下很多逻辑判断,函数调用
之类的代码,会使得bbsd的代码量过大,难以维护和扩展,而做成外部执行程序
的话,可以简化代码,做优化的时候逻辑简单,不容易出错.
最好的方式就是只将用户常用的功能放进bbsd,管理,talk,之类的不常用的功能
放入到外部执行程序里,这样也可以节省一定的内存
--
修改:say FROM 166.111.168.8
FROM 166.111.168.8