defphilip

用 scoket 写 ipc ，你写到倒是简单啊，有没有考虑过后续处理用户反馈的痛苦？

在我们这里的一个核心组件，为了照顾 android 要常驻后台，必须进程间通讯，并且为了跨平台，硬是把组件的调用方式改成了 socket （甚至 windows 都不是多进程的），天天都有用户反馈为什么这个有问题，那个有问题，一大半都是这个 socket 通信的问题

没有跨平台的需求，那就肯定选命名管道，甚至有跨平台需求给我来做也做管道，socket 那么通用为什么 chromium 做 ipc 的 mojo 在 windows 上不用？

楼上很多人就是 linux 后台做多了把后台的想法照搬到客户端上，完全没考虑到 windows 的复杂环境下用户很有可能直接 127 都连不上（比如用户选择联网的时候误选了防火墙选项）。更别说你们是安全软件。这样相当于把后门给别人留足了。

里面的 template 完全就不难啊。。。就一堆类型推导

这里是因为 Windows 的内存算法导致的，为什么要降低这个占用？我机子 32G 内存开机直接 16G 占用，占用多说明利用率充分。你的内存买来是拿来用的，不是拿来看的

把核心的计算程序，串口读写全部封装到 C++代码上，包括开线程，然后通过事件通知的方式回调告诉主线程，这样你就可以在同一个进程空间内干这两件事情，并且你还能享受到 python 的部分遍历

另外既然都用 Qt 了，为何不选择直接用 C++ Qt 完成呢？

浏览器的客户端完全是为了妥协人手不足，同时也要有点跨平台需求的情况
至于性能肯定比不上全原生的，特别是原生的控件有硬件加速的支持下，这点在 mac 上比较明显，windows 上什么乱七八糟的程序都有，甚至大部分程序都停留在 GDI 绘制层面上，那可能和浏览器客户端比不相上下

正确的做法，是不要去停止线程，线程正常消亡才是正常的逻辑
要做取消，可以在外部设置类似于 disable 一样的标志位，线程内函数判断这个标志

开几千个线程的爬虫。。。。系统吃的消吗
真的想用多线程，开个线程池几个线程并发跑就好了