all values placed into these data structures will be serialised 有很大的问题

[dignfei]

数据不应该被序列化。被序列化会影响性能，很大的影响实用性。当线程之间需要共享小数据可以使用redis等，不需要这个。当线程之间需要共享大型的数据（比如占用内存1Gb的数组），就需要共享的时候不序列化，能直接共享

[feamsr00]

Firstly as a public service....

Data should not be serialized. Serialization affects performance and greatly affects usability. When you need to share small data between threads, you can use redis and so on. You don't need this. When threads need to share large data (such as an array of 1Gb of memory), they need to be serialized when sharing.
-- Courtesy of GTranslate

Secondly, why? It seems your reasoning is, backwards? If I want to operate on large data structures, would it not make more sense to operate on them in a pragmatic, native, and structured way? If I'm working on large coherent data, then shouldn't I be using a structured data storage\retrieval mechanism (such as redis) to avoid the very issues that you mentioned?

Conversely, wouldn't most of these concerns be moot for small scalar values? If I'm shoving (repeatedly, rapidly, or both) simple strings, flags, counters, etc in and out of a thread, wouldn't the absolute processing time of spinning up calls to external data store systems be orders of magnitude slower then simply un\serialize()? (Make no mistake, non-native structured data is always marshaled/serialized at some point. Unless you want to grep strings forever!)

Granted there are ways to more closely bridge that speed gap (shared memory), or even for a more flexible architecture (sockets for off host communications). By and large, however, simple serialization
seems to just be better option (easier to implement, narrower in focus, simper in 90% of all use cases) for a thread library\extension like pht.

Does that make sense? Is there something about your rationale that wasn't apparent to me?