[rabbitmq-discuss] rabbitmq-c

[Tony Garnock-Jones]

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 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;
  somefun(v);

or simply:

  somefun(*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.


Regards,
  Tony
-- 
 [][][] 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