Standard IPC for Python?
philip at semanchuk.com
Wed Jan 14 03:53:57 CET 2009
On Jan 13, 2009, at 6:41 PM, Mel wrote:
> Philip Semanchuk wrote:
>> I'm working on message queue support, but the Sys V IPC API is a
>> headache and takes longer to code against than the POSIX API.
> I hadn't found it that bad. I have a C extension I should perhaps
> clean up
> and make public.
Have you compared the SysV objects to the POSIX objects? I'll give you
two examples of how SysV is more trouble with which to work.
Example 1 ---
The SysV objects expose a ton of information that show up as Python
attributes. For instance, a sysv_ipc.Semaphore object has 16
attributes: key, id, value, undo, block, mode, uid, gid, cuid, cgid,
last_pid, waiting_for_nonzero, waiting_for_zero and o_time. The first
two and last eight are read-only, the middle six are read-write.
Contrast this to a posix_ipc.Semaphore object which has two read-only
attributes: name and value.
All of those attributes on the SysV object add up to a lot of code.
Furthermore, the SysV attributes have types of key_t, mode_t, uid_t,
gid_t, pid_t, time_t, etc. I've spent the past few days researching
these types and trying to find out whether they're signed or unsigned,
guaranteed to fit in a long, etc. I also need to know what Python
types are appropriate for representing these. For instance, anything
that can exceed a C long can also exceed a Python int, and so I need
to return a Python long object if the C value exceeds LONG_MAX.
When I returned to the sysv_ipc code a few days ago, my intention was
to add message queue support to it, but instead I've gotten distracted
chasing type-related bugs that won't show up until e.g. someone
compiles the module on a 64-bit platform and tries to use a key that
exceeds 0xFFFFFFFF, or compiles it on some weird 16-bit embedded
processor that exposes another of my flawed type assumptions. The
POSIX API is so much simpler that I spend much less time working on
Example 2 ---
SysV shared memory has to be attached and detached and accessed with
the un-Pythonic read & write methods. I'd like to support buffer-type
access (like slicing), but that's more code to be written. And there's
another 16 attributes to expose.
POSIX shared memory OTOH is mmapped, and there's already a Python
library for that. For posix_ipc.SharedMemory objects I had to write a
constructor, an unlink() method, and code for three read-only
attributes and I was done. Nice.
I invite you to look at my extension and compare:
Maybe your code can benefit from what I've done, or vice versa.
More information about the Python-list