"I checked it out and it looks good, but I also heard that processes, unlike threads, can't share a lot of information..."
This is only partially true.
Threads are part of a process -- threads share memory trivially. Which is as much of a problem as a help -- two threads with casual disregard for each other can overwrite memory and create serious problems.
Processes, however, share information through a lot of mechanisms. A Posix pipeline (a | b
) means that process a and process b share information -- a writes it and b reads it. This works out really well for a lot things.
The operating system will assign your processes to every available core as quickly as you create them. This works out really well for a lot of things.
Stackless Python is unrelated to this discussion -- it's faster and has different thread scheduling. But I don't think threads are the best route for this.
"I think my program will need to share a lot of information."
You should resolve this first. Then, determine how to structure processes around the flow of information. A "pipeline" is very easy and natural to do; any shell will create the pipeline trivially.
A "server" is another architecture where multiple client processes get and/or put information into a central server. This is a great way to share information. You can use the WSGI reference implementation as a way to build a simple, reliable server.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…