My Python extensions
are alternatives to the modules for IPC
(inter-process communication) in the Python standard library.
They provide direct access to the low-level IPC primitives semaphores,
shared memory and message queues. If you don't need low-level access, you're
likely to find a higher level module like Python's
multiprocessing easier to use.
I'm the author of
sysv_ipc and I maintain
the other module mentioned
which is deprecated). They're all open
source and do similar things. For the most part, they only work on Unix, but
posix_ipc also works on Windows with Cygwin (see below).
Vladimir Marangozov wrote
shm sometime in the 1990s. I adopted
it in 2007. It provides access to System V semaphores and shared memory.
The interface has some un-Pythonic parts, so I added a Python wrapper to make it a little easier to work with. My wrapper is a bit of a kludge. I've made minimal changes to the C code, and I don't plan to make any more.
In 2008 I wrote two new modules,
The former is similar to
shm in that it provides access to
System V IPC objects. Since it's all new code (and all mine), it's
easier for me to debug and extend.
The latter (
posix_ipc) is totally new; I don't know of any
previous module that
made POSIX IPC objects available to Python programmers. Since System V
IPC is available in more places than POSIX IPC, this addition isn't
exactly revolutionary, but it is nice to have.
posix_ipc if at all possible. I recommend
it because POSIX IPC's design was informed by the strengths and weaknesses
that years of use revealed in System V IPC. As a result, it's less quirky and
less complicated, which means that your
code and mine is less likely to contain bugs.
Since POSIX IPC is easier to work with, I implement new features there
first and port them over to
sysv_ipc as I have time.
For Windows users,
compiles and runs its demos against the Cygwin 1.7 beta released in
late September 2010.
Sysv_ipc is a good fallback
if POSIX IPC is broken on a platform you need to support.
The semaphore and message queue interfaces of
sysv_ipc are similar so switching between one and the other should
not be too difficult. The shared memory interface is pretty different, though.
Shm should be your choice of last resort.
There's nothing wrong with it, but since it is not being developed
anymore you'll eventually have to replace it with one of the other
two modules. The only reason you might want to consider using
shm versus one of the other modules is if you need to support
Python ≤ 2.3 and you've proved that
sysv_ipc won't work.
All of the modules support basic use of inter-process semaphores and shared memory. The table below highlights some of the differences between the three modules.
|Oldest Python version supported||Tested w/Python 2.4.4, may work with older versions||Tested w/Python 2.4.4, may work with older versions||Tested w/Python 2.3, may work with older versions|
|Works with Python 3.x||Yes||Yes||No|
|Platforms supported||Linux, OpenSolaris, OS X (partial), FreeBSD ≥ 7.2||Linux, OpenSolaris, OS X (partial), FreeBSD||Linux, OpenSolaris, OS X, FreeBSD|
|Future development likely||Yes||Yes||No|
|Permit multiple semaphore acquisitions or releases in a single call||No||Yes||No|
|Exposes a semaphore's "otime"||Not applicable||Yes||No|
|Permits platform-specific creation flags||Yes||Yes||No|
|Provides subclassable classes||Yes||Yes||No|
|Follows PEP 8 naming conventions||Yes||Yes||No (mea culpa)|
|Provides functions to map SysV keys to ids and test if a key is in use||Not applicable||No||Yes|