Bill Janssen <janssen at parc.com> wrote: > > > The best way to make people stop complaining about the GIL and start > > using > > process-based multiprogramming is to provide solid, standardized support > > for process-based multiprogramming. > > And the model provided by the thread abstraction is a good API for that > support... While creating a thread is generally quite easy, the threading abstraction assumes globally shared memory. Certainly there are multiprocessing systems which handle transferring of data between disparate memories automatically (Linda/PyLinda, POSH, etc.), but no doubt some users will want a more fine-grained control of data transfer (and this is saying nothing of the shared-memory model's currently horrible performance in Python). As such, there is always the option of using the tried and true MPI and PyMPI, which looks to have been recently updated. Or even XMLRPC and PickleRPC over sockets and/or mmap'd files. Then again, with how easy it is to distribute workloads using (Py)Linda, I'd be hard pressed to suggest any other module for multiprocessing into the standard library (unless it was a work-alike)...though perhaps we should wait until it has been sped up a bit, supports more data types, etc. - Josiah
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4