大整数算法，可能会有耗时很长的计算，为了不影响用户的 UI 操作，
请教大家：比较好的解决方案，是用多线程？还是多进程？
用前者的话，算法库里得经常查看一个bool变量，来决定是否终止计算，有性能损耗；
用后者的话，算法库内部设计会更单纯，但调用者需处理数据传输等，门槛会比较高。
我比较倾向多进程。但要终止计算不也需要查个标志变量吗？难道直接结束进程？
多进程就比较灵活了，算法库是独立的，都不一定要和GUI部署到一个电脑上，以后要扩展分布计算也相对容易。
输入输出用就cin，cout，加个telnet外壳还可以远程使用。
gxqcn 发表于 2020-4-15 08:18
大整数算法，可能会有耗时很长的计算，为了不影响用户的 UI 操作，
请教大家：比较好的解决方案，是用多线 ...
为啥多线程反而会有性能损耗呢？
又不是python……
我看过的不少程序都是多线程（本地）+多进程（集群）的架构
为了防止用户 UI 假死，或者为了用户可以在计算中途能 Cancel，
就不能把 UI 线程与工作线程合并成一个线程。
如果是用多线程处理，
工作线程可以接收到 UI 线程下达的取消当前计算的命令，
算法库为了响应该指令，它就得时不时查询一下某个变量，看是否下达了该指令。
如果是用多进程处理，
当用户想取消当前的计算，只要把工作进程枪毙掉即可，
算法库设计会很单纯，无需检查是否需提前退出，闷着头干活就对了。
【背景资料】
昨天，将半成品给公司的技术总监（也是位大牛）演示交流了下，
针对UI 防假死问题，他建议我用多进程，说好处多多，
而我还没有多进程开发的经验，甚至很少写带 UI 的应用程序，
所以才把这个话题抛出来，让大家讨论讨论，
毕竟开发出的算法库，初衷是分享给大家用的，
若仅仅是我自己一个人关着门写着玩，那 UI 是非必需的，多线程/多进程也是非必需的。
如果通过多进程，可以保证用户的 UI 不会假死，那我会考虑学习一下多进程的开发。
多进程肯定可以保证UI不假死，但一般这个UI本身需要多线程，即有一个线程专门负责和算法库去通信，再有一个线程负责和用户交互。
进程间通信的方式就很多了，最简单的就是标准IO重定向，算法库用cin接收输入，cout输出就行了。
要说缺点也是有的，就是输入输出这块比较复杂，不像函数调用那样直接了。输入输出信息非常多的时候可能会比较慢。
gxqcn 发表于 2020-4-15 08:18.
用前者的话，算法库里得经常查看一个bool变量，来决定是否终止计算，有性能损耗；
用后者的话，算法库内部设计会更单纯，但调用者需处理数据传输等，门槛会比较高。
1) 如无特别的需求,基本上都是选择多线程的. 因为多线程比多进程的总资源开销要低很多.
[除非某些特别的原因才会选择多进程, 比如 子任务可能会崩溃,导致主线程[整个软件]也崩溃. 如果要求软件无论如何也不能崩溃,即便是算法库崩了,软件也不能崩,那么只能是多进程了.]
2) 算法库是属于计算密集型的任务, 然后算法结果的后期处理与输出是属于IO类型的任务.把计算和IO处理分开是推荐做法.
3) UI 是属于IO类型的, 主线程 是一个总的IO事件处理器 就可以了. 然后计算任务与IO事件处理器之间的通信通常走的是消息信号, 在此我个人 强烈推荐用Qt这种 异步风格的GUI. 支持几乎所有的平台,而且社区太成熟了
应该是既不是多进程，也不是多线程，而是轻量级异步
一般比较耗时的操作都会另起一个线程，这样UI操作基本不受影响。还可以随时控制进度，比如cancel。看情形你是把UI和计算混一块写了，比较好的做法是把计算功能独立出来写，UI将来可以随便换成什么都可以。方法通用，操作简单，容易移植。
错！我的计算部分是独立的DLL，现在用的是独立的线程（内部还有个线程池），UI 是另一个线程，可随时 cancel
要讨论的是调用算法库部分，是用独立的线程，还是独立的进程？前者对调用者简单，后者对库开发者简单。
这个当然是线程了，创建一个线程要比创建过程要快很多。开发出来是为了让别人用而不是自己玩。