※ 引述《reader (读者)》之铭言： : ※ 引述《in2 (敬请期待 :P)》之铭言： : : 我知道这样子很占板面, 可是这样子做有几个好处: : : 1. : : 因为目前 .DIR 是 linear 存的 : : (即第一篇放在 0*sizeof(fileheader_t) , 第二篇放在 1*sizeof(fileheader_t)) : : 於是要清掉中间其中一篇, 是会导致大量的资料搬动的, : : 尤其如果又在尖锋时段, 系统 loading很高的时候再加上那个板很大的时候, : : 这样做一点都不是好主意. : 但是绝大多数时候，都是删除最近的文章，搬移动作对於系统的 : 负担，并不太大。例如两岸板大多数时候，都是删除刚转进来的 : 文章。 : 又或者如果是搬移太前面的文章，才使用 (本文已被删除)。 @_@ : : 2. : : 因为推文、修文会把 fileheader_t 写到 .DIR 原来的地方, : : 如果原来的地方被压掉的话, 就会烂掉 (所谓黑洞一类的) : : 所以使用 (本文已被删除) 其实可以大量避免黑洞的问题. : 我没有看过 ptt 的原始码，但早期的 bbs 都有总文章数的设计， : 顶多是造成推文推错或推文数不对，而修文更只是纯档案的操作， : 并不需要写入什麽资讯在 .DIR, 理论上会造成问题的，只有新增 : 文章才对。可以简单解释一下吗? 这个我前面已经解释过了 @@ : : 我觉得现在机器的 loading已经够大了, : : 做一些很暴力的事情 (像是 semaphore) 并不是好主意 @@ : : 而且我也想不到要怎麽用比较好? : : 一个板一个 semaphore? : : 每次有人要读/ 写就去 lock 那个 semaphore ? : : 那 performance会烂掉 :p : : 我还是觉得用本文已删除最好 ;p : 新增文章和删除文章才需要吧。而且也能透过各板的 busy flag : 单用两个 simaphore 达成 mutex 的效果。 光是新增和删除要, 这个量就大的不得了了. 而且请麻烦参考我前面写的文章, 就算是 mutex还是不会解决目前碰到的问题. : 其实 256 个 simaphore 才用到一个 IPC key, 可以制造 128 组 : mutex, 并不是那麽占用系统资源的事，虽然我没试过 loading : 很大的状况，但也不曾觉得 simaphore 很暴力很伤效能，又不是 : 要用 Dijkstra 演算法手动自行制造 mutex. 我还没有看过 kernel source , 并不知道实际 simaphore 是怎麽 implement , 只是想起来就很伤 ^^;;; 尤其如果又是用 spin-lock做的话 :p : 如果现在的 ptt 已改成 multi-threading (应该是吧), 那麽还 : 能使用 pthread_mutex_lock 的方式，更节省系统资源，不过没 : 试过效能如何就是了。 不是, 我们现在还是 multi-process 架构. 目前大部份的 bbs也都是使用 multi-process , multi-threading 目前我只有听过天火. 也许 colabbs也可以算是 multi-threading, 不过 colabbs performance太差, 当然不考虑. : 这都不用大改程式码，不然我更推荐用 thread/process + pipe : 专门处理资料新增和删除，亦即 resource manager 的做法，就 : 不会有那麽多奇奇怪怪的资源共享问题了。 与其这样子的话, 倒不如用我想的某个方式. 在 SHM中, 开个新的 array, 对於每个板给一个 char vstate (共花费 MAX_BOARD bytes) 如果有发生砍文章的动作 (包括 expire) 就把该值加一. 在输入推文前以及进入修改文章前, 自己先纪录一下当时的 vstate. 等到要写入 .DIR 之前, 再核对一下和当前 SHM中的一不一样. 如果一样的话就写入, 不一样的话就推荐失败/ 修文失败 (存进暂存档) 这样子听起来明显会有 race , 不过就目前的情况看起来应该会好的多/ 可以解决大部份的情况. 等到真的 race 再来手动修就是 :p -- 「假设上天只给我爱情或微积分, 我愿选择一生的幸福」 -- ψ 中华人民共和国 1981-未决 --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 140.112.30.144