python module compatibility with 3.x (and 2.6+)

[crackwitz]

Enabling pre-2.6 requires getting rid of that bytesobject.h compat header and defining what's needed manually. I figured to leave it alone until someone asks for pre-2.6.

I have tested this a little. I see no compiler errors or warnings and opening a channel and getting from it works as expected. the most confusing thing was python's refcounting and whether the incref was really needed. I believe all the changes (in particular the PyLong_FromLong uses) are okay.

I'm planning changes to the python side that make get/put a little easier (create buffer implicitly, ...) that will get its own pull request.

[ndantam]

Would you be willing to contribute some test cases for this? We're not currently using the python bindings in my group, so I don't have any tests ready to go. Ideally, we would call the python tests along with all the others in make check.

[crackwitz]

makes sense. I'll take a look.

by the way: when calling ach_open, is there any public way to get frame_cnt and frame_size, or at least the product of both? I'm wondering if there's a convenient upper size to use for implicit buffer creation. I'm hesitant to just call ach_get twice (once to get message size) because race condition.

[ndantam]

makes sense. I'll take a look.

Thanks, I've put together some initial continuous integration tests using Docker and Travis in dev/contint (0ba3ab5). Not currently building the python module in those tests. I have travis+docker+python2 working in another project, but maybe you have something better for python3.

when calling ach_open, is there any public way to get frame_cnt and frame_size

For userspace channels, one could read the struct ach_header in the shared memory. I don't think this is exposed in kernel channels. There are already a few accessors to get channel attributes (e.g., ach_channel_clock(). No harm in adding a few more, though there may be a better way to do what you seem to want:

I'm wondering if there's a convenient upper size to use for implicit buffer creation. I'm hesitant to just call ach_get twice (once to get message size) because race condition.

I use memory regions. For my usage, at least, I don't see any race conditions to expand the region on ACH_OVERFLOW.

• https://github.com/golems/amino/blob/master/include/amino/mem.h#L198
• https://github.com/golems/sns/blob/master/src/msg.c#L52