Standard IPC for Python?

[Philip Semanchuk]

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  
type-related drudgery.

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:
http://semanchuk.com/philip/sysv_ipc/

Maybe your code can benefit from what I've done, or vice versa.


Good luck
Philip