tonyg at lshift.net
Wed Sep 30 14:13:49 BST 2009
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 structs
> 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 think.
> So I took amqp_api.c, and wrote amqp_api_p.c which accepts pointers to
> structs rather then copy by value. These functions just create take
> the pointers, copy to local vars and then calls the existing functions.
That sounds reasonable. I notice that there aren't many functions that
*return* structs, and those that do are special anyway.
I wonder whether you're doing this:
amqp_bytes_t v = *arg;
> In general I see a few solutions to the problem of wrapping rabbitmq-c
> 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 with
the ruby interface to libffi?
> 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.
 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