scott.brooks at epicadvertising.com
Wed Sep 30 16:41:30 BST 2009
On 2009-09-30, at 9:13 AM, Tony Garnock-Jones wrote:
> Hi Scott,
> Scott Brooks wrote:
>> Although passing the amqp_bytes_t as a struct is a really great
>> solution to C strings, passing structs by value, and returning
>> is not supported by libffi/ruby-ffi(as far as I could test anyways).
> Yes, it seems like a slightly edgy thing to do even in a C API, I
>> So I took amqp_api.c, and wrote amqp_api_p.c which accepts pointers
>> structs rather then copy by value. These functions just create take
>> the pointers, copy to local vars and then calls the existing
> That sounds reasonable. I notice that there aren't many functions that
> *return* structs, and those that do are special anyway.
Yeah, amqp_cstring_bytes is the main one that returns a struct.
> I wonder whether you're doing this:
> amqp_bytes_t v = *arg;
> or simply:
Actually I'm doing something worse!
memcpy(&body, in_body, sizeof(body);
But gcc does a good job on -O1 and above and replaces the memcpy.
>> In general I see a few solutions to the problem of wrapping
>> for use in higher level languages.
>> A: don't support it
> ... thus providing a slight impetus for those languages to make their
> FFI able to cope with structs-by-value :-)
> Is the lack of structs-by-value a libffi thing, or is it a problem
> the ruby interface to libffi?
Looking at the unit tests for libffi, it looks like they pass by
I wrote a patch to handle returning structs for ruby-ffi, and then got
handling the pass struct by value because I forgot that the shared
would have a well defined interface for that.
>> B: keep a parallel set of pass by pointer functions so either API can
>> be used(currently it just copies the data passed to the pointer, and
>> then calls the pass by value functions)
> Possible, possible. How are you thinking of dealing with AMQP tables?
> They're a little more complex than amqp_bytes_t - a simple
> pointer-passing strategy might not work so well.
>> C: change the whole API to pass pointers.
> I don't like this idea.
I guess option D is revisiting ruby-ffi and trying to get the pass
value code working, which looks to be the route I'll try and take.
>  Tony Garnock-Jones | Mob: +44 (0)7905 974 211
>  LShift Ltd | Tel: +44 (0)20 7729 7060
>   http://www.lshift.net/ | Email: tonyg at lshift.net
More information about the rabbitmq-discuss