[Python-ideas] Python 3000 TIOBE -3%
sturla at molden.no
Sat Feb 11 15:01:47 CET 2012
Den 11.02.2012 07:15, skrev Nick Coghlan:
> Why is that relevant? If free threading is the all-singing all dancing
> wonderment you believe:
> 1. Fork CPython
> 2. Make it free-threaded (while retaining backwards compatibility with
> all the C extensions out there!)
> 3. Watch the developer hordes flock to your door (after all, it's the
> lack of free-threading that has held Python's growth back for the last
> two decades, so everyone will switch in a heartbeat the second you, or
> anyone else, publishes a free-threaded alternative where all their C
> extensions work. Right?).
There are several solutions to this, I think.
One is to use one interpreter per thread, and share no data between
them, similar to tcl and PerlFork. The drawback is developers who forget
to duplicate file handles, so one interpreter can close a handle used by
Another solution is transactional memory. Consider a database with
commit and rollback. Not sure how to fit this with C extensions though,
but one could in theory build a multithreaded interpreter like that.
> If a fraction of the energy that people put into asking for free
> threading was instead put into asking "how can we make inter-process
> communication better?", we'd no doubt have a good shared object
> implementation in the mmap module by now (and someone might have
> actually responded to Jesse's request for a new multiprocessing
> maintainer when circumstances forced him to step down).
I think I already explained why BSD mmap is a dead end. We need named
kernel objects (System V IPC or Unix domain sockets) as they can be
communicated between processes.
There is also reasons to prefer SysV message queues over shared memory
(Sys V or BSD), such a thread safety. I.e. access is synchronized by the
kernel. SysV message queues also have atomic read/write, unlike sockets,
and they are generally faster than pipes. With sockets we have to ensure
that the correct number of bytes were read or written, which is a PITA
for any IPC use (or any other messaging for that matter). In the
meanwhile, take a look at ZeroMQ (actually written ØMQ). ZeroMQ also
have atomic read/write messages.
More information about the Python-ideas