※ 引述《in2 (敬請期待 :P)》之銘言：
: ※ 引述《reader (讀者)》之銘言：
: : 在 PTT 兩岸板，因為大量的爭議性轉信文章，而導致板務
: : 再怎麼努力刪文，每天都會留下數百篇 "(本文已被刪除)"
: : 而沒有辦法解決閱讀不便的問題。
: : 有時能趁著凌晨人少時清掉 "(本文已被刪除)"，但終歸是
: : 留下了一整天，意義不大。
: : 希望能不要留下 "(本文已被刪除)", 這樣真的很佔板面。
: : 我不知道問題在哪裡，推文、修文的寫入應該可以用 file
: : name 而不需要動到 board index, 但現在卻會有這個現象
: : 導致黑洞。
: 我知道這樣子很佔板面, 可是這樣子做有幾個好處:
: 1.
: 因為目前 .DIR 是 linear 存的
: (即第一篇放在 0*sizeof(fileheader_t) , 第二篇放在 1*sizeof(fileheader_t))
: 於是要清掉中間其中一篇, 是會導致大量的資料搬動的,
: 尤其如果又在尖鋒時段, 系統 loading很高的時候再加上那個板很大的時候,
: 這樣做一點都不是好主意.
但是絕大多數時候，都是刪除最近的文章，搬移動作對於系統的
負擔，並不太大。例如兩岸板大多數時候，都是刪除剛轉進來的
文章。
又或者如果是搬移太前面的文章，才使用 (本文已被刪除)。
: 2.
: 因為推文、修文會把 fileheader_t 寫到 .DIR 原來的地方,
: 如果原來的地方被壓掉的話, 就會爛掉 (所謂黑洞一類的)
: 所以使用 (本文已被刪除) 其實可以大量避免黑洞的問題.
我沒有看過 ptt 的原始碼，但早期的 bbs 都有總文章數的設計，
頂多是造成推文推錯或推文數不對，而修文更只是純檔案的操作，
並不需要寫入什麼資訊在 .DIR, 理論上會造成問題的，只有新增
文章才對。可以簡單解釋一下嗎?
: : 新增文章跟刪除文章之間，即使不使用 file lock, 或是
: : 更正式一點建立 resource manager, 也可建立簡單的機制
: : 來解決，正規一點用 semaphore, 要不然即使只用簡單的
: : shared memory + sleep 也能在多數狀況下沒有問題才對。
: : 略為看過相關討論，似乎爭議點是在 file lock 的上限，
: : 在大站很容易達到，但不使用 lock 的方法有很多，不必
: : 總是卡在那裡吧?
: 我覺得現在機器的 loading已經夠大了,
: 做一些很暴力的事情 (像是 semaphore) 並不是好主意 @@
: 而且我也想不到要怎麼用比較好?
: 一個板一個 semaphore?
: 每次有人要讀/ 寫就去 lock 那個 semaphore ?
: 那 performance會爛掉 :p
: 我還是覺得用本文已刪除最好 ;p
新增文章和刪除文章才需要吧。而且也能透過各板的 busy flag
單用兩個 simaphore 達成 mutex 的效果。
其實 256 個 simaphore 才用到一個 IPC key, 可以製造 128 組
mutex, 並不是那麼佔用系統資源的事，雖然我沒試過 loading
很大的狀況，但也不曾覺得 simaphore 很暴力很傷效能，又不是
要用 Dijkstra 演算法手動自行製造 mutex.
如果現在的 ptt 已改成 multi-threading (應該是吧), 那麼還
能使用 pthread_mutex_lock 的方式，更節省系統資源，不過沒
試過效能如何就是了。
這都不用大改程式碼，不然我更推薦用 thread/process + pipe
專門處理資料新增和刪除，亦即 resource manager 的做法，就
不會有那麼多奇奇怪怪的資源共享問題了。
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 61.222.173.26