RSS
The Python extension module posix_ipc gives access to POSIX inter-process semaphores, shared memory and message queues on systems that support the POSIX Realtime Extensions a.k.a. POSIX 1003.1b-1993. That includes most (all?) Linuxes with kernel ≥ 2.6, OpenSolaris ≥ 2008.05 and FreeBSD ≥ 7.2.
OS X and other Unix-y platforms (including Windows + Cygwin 1.7) provide partial (or partially broken) support. See the platform notes below for more details.
This module is known to work with Python 2.4 – 3.3 (but not 3.0). It is released under a BSD license.
You might be interested in the very similar module sysv_ipc which provides Python access to IPC using System V semaphores, shared memory and message queues. System V IPC has broader OS support but is a little less easy to use and usually lags behind this module a little.
You can download posix_ipc version 0.9.8 [MD5 sum] [SHA1 sum] which contains the source code, setup.py, installation instructions and sample code. The exact same posix_ipc tarball is also available on PyPI.
You might want to read all of the changes in this version and about some known bugs.
Note that this module doesn't support unnamed (anonymous) POSIX semaphores.
Jump to semaphores, shared memory, or message queues.
O_TRUNC is only useful when creating SharedMemory objects.
As far as I know, this is only False under OS X.
As far as I know, this is only False under OS X.
In addition to standard Python errors (e.g. ValueError), this module raises custom errors. These errors cover situations specific to IPC.
This is a handle to a semaphore.
name must be None or a string. If it is None, the module chooses a random unused name. If it is a string, it should begin with a slash and be valid according to pathname rules on your system, e.g. /wuthering_heights_by_semaphore
The flags specify whether you want to create a new semaphore or open an existing one.
The timeout (which can be a float) specifies how many seconds this call should wait, if at all.
On platforms that don't support the sem_timedwait() API, a timeout > 0 is treated as infinite. The call will not return until its wait condition is satisfied.
Most platforms provide sem_timedwait(). OS X is a notable exception. The module's Boolean constant SEMAPHORE_TIMEOUT_SUPPORTED is True on platforms that support sem_timedwait().
You must call close() explicitly; it is not called automatically when a Semaphore object is garbage collected.
Note, however, that once a semaphore has been unlinked, calls to open() with the same name should refer to a new semaphore. Sound confusing? It is, and you'd probably be wise structure your code so as to avoid this situation.
These semaphores provide __enter__() and __exit__() methods so they can be used in context managers. For instance --
with posix_ipc.Semaphore(name) as sem:
# Do something...
Entering the context acquires the semaphore, exiting the context releases the semaphore. See demo4/child.py for a complete example.
This is a handle to a shared memory segment. POSIX shared memory segments masquerade as files, and so the handle to a shared memory segment is just a file descriptor that can be mmapped.
name must be None or a string. If it is None, the module chooses a random unused name. If it is a string, it should begin with a slash and be valid according to pathname rules on your system, e.g. /four_yorkshiremen_sharing_memories
On some systems you need to have write access to the path.
The flags specify whether you want to create a new shared memory segment or open an existing one.
When opening an existing shared memory segment, one can also specify the flag O_TRUNC to truncate the shared memory to zero bytes.
You must call close_fd() or os.close() explicitly; the file descriptor is not closed automatically when a SharedMemory object is garbage collected.
Closing the file descriptor has no effect on any mmap objects that were created from it. See the demo for an example.
The POSIX specification for shm_unlink() says, "Even if the object continues to exist after the last shm_unlink(), reuse of the name shall subsequently cause shm_open() to behave as if no shared memory object of this name exists (that is, shm_open() will fail if O_CREAT is not set, or will create a new shared memory object if O_CREAT is set)."
I'll bet a virtual cup of coffee that this tricky part of the standard is not well or consistently implemented in every OS. Caveat emptor.
This is a handle to a message queue.
name must be None or a string. If it is None, the module chooses a random unused name. If it is a string, it should begin with a slash and be valid according to pathname rules on your system, e.g. /my_message_queue
On some systems you need to have write access to the path.
The flags specify whether you want to create a new queue or open an existing one.
Max_messages defines how many messages can be in the queue at one time. When the queue is full, calls to .send() will wait.
Max_message_size defines the maximum size (in bytes) of a message.
Read and write default to True. If read/write is False, calling .receive()/.send() on this object is not permitted. This doesn't affect other handles to the same queue.
The message string can contain embedded NULLs (ASCII 0x00). Under Python 3, the message can also be a bytes object.
The timeout (which can be a float) specifies how many seconds this call should wait if the queue is full. Timeouts are irrelevant when the block flag is False.
The priority allows you to order messages in the queue. The highest priority message is received first. By default, messages are sent at the lowest priority (0).
If the queue is empty, the call will not return immediately. The timeout parameter controls the wait just as for the function send().
Message queues accept only one notification request at a time. If another process has already requested notifications from this queue, this call will fail with a BusyError.
The operating system delivers (at most) one notification per request. If you want subsequent notifications, you must request them by calling request_notification() again.
You must call close() explicitly; it is not called automatically when a MessageQueue object is garbage collected.
This module comes with three demonstrations. The first (in the directory demo) shows how to use shared memory and semaphores. The second (in the directory demo2) shows how to use message queues. The third (demo3) shows how to use message queue notifications.
IPC objects are a little different from most Python objects and therefore require a little more care on the part of the programmer. When a program creates a IPC object, it creates something that resides outside of its own process, just like a file on a hard drive. It won't go away when your process ends unless you explicitly remove it. And since many operating systems don't even give you a way to enumerate existing POSIX IPC entities, it might be hard to figure out what you're leaving behind.
In short, remember to clean up after yourself.
I know it's verboten to talk about pointers in Python, but I'm going to do it anyway.
Each Semaphore object created by this module contains a C pointer to the IPC object created by the system. When you call sem.close(), the object's internal pointer is set to NULL. This leaves the object in a not-quite-useless state. You can still call sem.unlink() or print sem.name, but calls to sem.aquire() or sem.release() will raise an ExistentialError.
If you know you're not going to use a Semaphore object after calling sem.close() or sem.unlink(), you could you set your semaphore variable to the return from the function (which is always None) like so:
my_sem = my_sem.close()
That will ensure you don't have any nearly useless objects laying around that you might use by accident.
This doesn't apply to shared memory and message queues because they're referenced at the C level by a file descriptor rather than a pointer.
It appears that the read and write mode bits on IPC objects are ignored by the operating system. For instance, on OS X, OpenSolaris and Linux one can write to semaphores and message queues with a mode of 0400.
When creating a new message queue, you specify a maximum message size which defaults to QUEUE_MESSAGE_SIZE_MAX_DEFAULT (currently 8192 bytes). You can create a queue with a larger value, but be aware that posix_ipc allocates a buffer the size of the maximum message size every time receive() is called.
Under OS X/Darwin, ftruncate() can be used to set the memory size once after the initial call to shm_open(). This module does that in the SharedMemory constructor, so subsequent attempts to resize the shared memory will fail.
I don't know if this holds true on all platforms. If your platform supports multiple calls to ftruncate(), you can call that via Python's os module, passing the file descriptor exposed in the SharedMemory object.
The posix_ipc module is just a wrapper around your system's API. If your system's implementation has quirks, the man pages for sem_open, sem_post, sem_wait, sem_close, sem_unlink, shm_open, shm_unlink, mq_open, mq_send mq_receive, mq_getattr, mq_close, mq_unlink and mq_notify will probably cover them.
For Pythonistas –
I don't know of any bugs in this code. However, under Python 3 the standard library modules accept bytes and bytearray objects for filenames in addition to strings. One could argue that this module should behave the same way.
Also, this module doesn't support Python 3 memory views, which it probably should (for shared memory objects). Support for that might come in a later version.
This module is just a wrapper around the operating system's functions, so if the operating system doesn't provide a function, this module can't either. The POSIX Realtime Extensions (POSIX 1003.1b-1993) are, as the name implies, an extension to POSIX and so a platform can claim "POSIX conformance" and still not support any or all of the IPC functions.
Under 7.2, posix_ipc's demos fail unless they're run as root. It's a simple permissions problem. Prefix the IPC object names with /tmp in params.txt and the problem goes away. I didn't see this behavior under FreeBSD 8.0, so it must have been fixed at some point.
If you don't have the sem and mqueuefs kernel
modules loaded, you'll get a message like this (or something
similarly discouraging) when you
try to create a semaphore or message queue:
Bad system call: 12 (core dumped)
Type kldstat to list loaded modules, and kldload sem or kldload mqueuefs if you need to load either of these. BTW, mqueuefs has some cool features.
Prior to 7.2, FreeBSD POSIX semaphore support was broken.
From what I can tell, OS X does not support sem_init() or sem_destroy(), so even if this module adds support for unnamed semaphores, they won't be available under OS X.
Versions of Cygwin prior to 1.7 didn't support POSIX IPC. Under Cygwin 1.7 beta 62 (released in early October 2009), posix_ipc compiles and runs both demos.