我是原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, 速度比较快些，优缺点大概主管的相反不知道我说的对不对，不过这两张图看起来你们没有谁是绝对正确或错误