我是原po, 先感謝各位前輩的指教和建議,
小弟覺得還是畫圖來解釋可能比較清楚.
我主管的想法: thought1
https://goo.gl/fz9ktO
我的想法: thought2
https://goo.gl/3dFlLi
其中,
thought1的game logic thread1 處理命令,
thought2的command handle,
都是同一個function,
只是由哪一個地方執行, 而有了爭議.
小弟以為, 按照我的想法, 可以減少重複的"聽"這個動作,
也減少不必要的IPC傳送, 還有一堆的Mutex.
還請各位指教指點.
感謝.

說真的 不管是大家覺得你的做法比較好 或是大家覺得主管的做法比較好 對你來說你都不會開心的吧...爭這幹嘛咧

反正interface你做 做成一個不就好了?

因為我想學習, 到底是我哪裡思考有盲點.

Server和Logic應該不是相對的吧?還是這邊的Logic指的是Client?另外建議原PO要不要先向主管詢問一下主管設計的理由與好處?第一篇看來,多半在講原PO自己設計的理由,但看不出主管想要

應該是指 server side 要跑的邏輯。

的設計，他的理由是什麼?只看到主管一直在堅持他的設計...在這種情況下,比起設計理念,我覺得溝通上的問題還比較大.

flowchart看不懂Orz

看了好久都看不懂,所以原po表達或許有問題?(也有可能是我有問題)不過看來是主管要client多出一個thread來接收server的command?我的意見:若是重要的中斷command,那要接收沒錯,一般的遊戲command就client自已處理就好了,所以多一個thread接收來自server的中斷沒什麼不妥

看不懂

主管1是玩家觀點，即時響應，實作難度高。原po是開發觀點，簡易安全的實作。

我跟你在做一模一樣的東西，我怎麼看都覺得這比較像工作分配的問題

主管的好處是不同process，好處是server不會因為logic掛掉而掛掉，然後不用管你那邊會hang住，缺點是耗損比較多performance跟速度你的應該比較像lib用法，好處容易debug, 速度比較快些，優缺點大概主管的相反不知道我說的對不對，不過這兩張圖看起來你們沒有誰是絕對正確或錯誤