- 主题:大牛来说说，py3.14的no-GIL对实际应用有什么用途？
我弄的那些也算计算密集型的。
IO 密集我一般用的 gevent 搞定。
【 在 poocp 的大作中提到: 】
: 这个自由线程功能主要用途是跑满CPU所有核心，适合计算密集型应用。对IO密集型的应用没啥提升。
--
FROM 110.87.26.*
进程间共享数据非常麻烦，很多场景下为了多进程需要大改数据结构甚至程序结构。
比如你有个dict需要在多任务间修改，多线程的话加个lock就解决，多进程的话就得加进程
间通信，不论是socket、共享内存、进程安全queue，都很麻烦。当共享的数据多起来时，就是灾难，不得不重新设计程序结构。
进程间如果不需要共享数据那就容易得多。
【 在 hgoldfish 的大作中提到: 】
: 现实的 Python 程序都是调用 Pool.map()，
: 不需要考虑多进程的创建开销。
--
FROM 116.237.207.*
“有个 dict 需要有多任务间修改”，这件事情在我看来就是错误啊。
设计并行程序需要从框架上抽象成 map/reduce 或者生产者/消费者。
我不管用进程、线程和协程，都不会直接调用这三者的基础设施。
【 在 RunningOn 的大作中提到: 】
: 进程间共享数据非常麻烦，很多场景下为了多进程需要大改数据结构甚至程序结构。
: 比如你有个dict需要在多任务间修改，多线程的话加个lock就解决，多进程的话就得加进程
: 间通信，不论是socket、共享内存、进程安全queue，都很麻烦。当共享的数据多起来时，就是灾难，不得不重新设计程序结构。
: ...................
--
FROM 110.87.26.*
手头一个大量字符串处理的玩意儿，从3.8升级到3.14，感觉是快了一些，不知道是不是错觉。
【 在 sah166 的大作中提到: 】
: 对大多数用户来说，无感
--
FROM 124.127.177.*
这正是我说的要大改程序的设计啊，这是你从上帝视角一开始就设计为并发任务才会这
么设计。
实际的需求是从实际的项目出发的，很多原本非并发的任务想改并发任务就很麻烦。
更不提还有相当多的任务它不一定能做出你想的那样的抽象。
【 在 hgoldfish 的大作中提到: 】
: “有个 dict 需要有多任务间修改”，这件事情在我看来就是错误啊。
: 设计并行程序需要从框架上抽象成 map/reduce 或者生产者/消费者。
: 我不管用进程、线程和协程，都不会直接调用这三者的基础设施。
: ...................
--
FROM 116.237.207.*