| Author |
Message |
|
| Guest |
 Posted: Fri Sep 25, 2009 4:52 pm |
 |
|
|
Guest
|
We have been using rabbitmq-c for quite a while internally, and it's
been working great for us.
I have built a ruby wrapper for rabbitmq-c using ruby-ffi which i
think we are planning on releasing soon, the only issue is that there
are some API decisions that make rabbitmq-c hard to use with FFI.
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).
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.
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
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)
C: change the whole API to pass pointers.
D: some other solution
Any thoughts as to which direction you would like to take
Thanks
Scott Brooks
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post received from mailinglist |
|
|
| Back to top |
|
| tonyg |
| Posted: Wed Sep 30, 2009 1:14 pm |
|
|
|
User
Joined: 07 Nov 2006
Posts: 199
|
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@lshift.net
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post received from mailinglist |
|
|
| Back to top |
  
|
| Guest |
| Posted: Wed Sep 30, 2009 3:43 pm |
|
|
|
Guest
|
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
>> 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.
Yeah, amqp_cstring_bytes is the main one that returns a struct.
>
> I wonder whether you're doing this:
>
> amqp_bytes_t v = *arg;
> somefun(v);
>
> or simply:
>
> somefun(*arg);
>
> ?
Actually I'm doing something worse!
amqp_bytes_t body;
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
>> 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?
Looking at the unit tests for libffi, it looks like they pass by
struct properly.
I wrote a patch to handle returning structs for ruby-ffi, and then got
stuck on
handling the pass struct by value because I forgot that the shared
library ABI
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
structs by
value code working, which looks to be the route I'll try and take.
>
>
> 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@lshift.net
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post received from mailinglist |
|
|
| Back to top |
|
| tonyg |
| Posted: Wed Sep 30, 2009 3:44 pm |
|
|
|
User
Joined: 07 Nov 2006
Posts: 199
|
Scott Brooks wrote:
> I guess option D is revisiting ruby-ffi and trying to get the pass
> structs by
> value code working, which looks to be the route I'll try and take.
Yep. I'd be *reasonably* happy supporting a parallel API for some of the
operations -- but it really only works well for the simple ones
(amqp_bytes_t). The complex ones will no doubt require special handling
anyway...
Tony
--
[][][] Tony Garnock-Jones | Mob: +44 (0)7905 974 211
[][] LShift Ltd | Tel: +44 (0)20 7729 7060
[] [] http://www.lshift.net/ | Email: tonyg@lshift.net
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post received from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Wed Sep 30, 2009 3:54 pm |
|
|
|
Guest
|
On 2009-09-30, at 11:44 AM, Tony Garnock-Jones wrote:
Quote: Scott Brooks wrote:
Quote: I guess option D is revisiting ruby-ffi and trying to get the pass |
|
|
| Back to top |
|
| Guest |
| Posted: Wed Oct 14, 2009 3:06 pm |
|
|
|
Guest
|
I've attached the bundle, hopefully I've generated that right.
changeset: 50:e0f5366d047c
tag: tip
parent: 48:943c20e50f0f
user: "Scott Brooks <scott.brooks@epicadvertising.com>"
date: Wed Oct 14 10:42:50 2009 -0400
files: librabbitmq/amqp.h librabbitmq/amqp_api.c librabbitmq/
amqp_socket.c
description:
Updated amqp_simple_rpc to take a 0 terminated array of
amqp_method_number_t replies
Updated AMQP_SIMPLE_RPC macro for the new format
Added AMQP_MULTIPLE_RESPONSE_RPC macro to take a 0 terminated array of
amqp_method_number_t replies
Added amqp_basic_get function
Added amqp_queue_purge function
Added amqp_get_rpc_reply function to expose amqp_rpc_reply when we are
not statically linking
Added amqp_data_in_buffer function to check to see if
amqp_simple_wait_frames will hit a blocking read
Post received from mailinglist |
|
|
| Back to top |
|
| tonyg |
| Posted: Wed Oct 14, 2009 4:55 pm |
|
|
|
User
Joined: 07 Nov 2006
Posts: 199
|
|
| Back to top |
|
| Guest |
| Posted: Wed Oct 14, 2009 5:21 pm |
|
|
|
Guest
|
On Oct 14, 2009, at 10:04 AM, Scott Brooks wrote:
> I've attached the bundle, hopefully I've generated that right.
>
> changeset: 50:e0f5366d047c
> tag: tip
> parent: 48:943c20e50f0f
> user: "Scott Brooks <scott.brooks@epicadvertising.com>"
> date: Wed Oct 14 10:42:50 2009 -0400
> files: librabbitmq/amqp.h librabbitmq/amqp_api.c librabbitmq/
> amqp_socket.c
> description:
> Updated amqp_simple_rpc to take a 0 terminated array of
> amqp_method_number_t replies
> Updated AMQP_SIMPLE_RPC macro for the new format
> Added AMQP_MULTIPLE_RESPONSE_RPC macro to take a 0 terminated array of
> amqp_method_number_t replies
> Added amqp_basic_get function
> Added amqp_queue_purge function
> Added amqp_get_rpc_reply function to expose amqp_rpc_reply when we are
> not statically linking
> Added amqp_data_in_buffer function to check to see if
> amqp_simple_wait_frames will hit a blocking read
Scott,
are you going to announce a new ruby amqp library based off of this
work?
cr
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post received from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Thu Oct 15, 2009 1:23 pm |
|
|
|
Guest
|
|
| Back to top |
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
