------art_20476_8158291.1159983820601
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 10/4/06, Serge Kruppa <serge.kruppa / simitel.com> wrote:
>
>
> Do you think it would be wise to implement a Ruby to C RPC mechanism on
> top
> of it? Thus instead of using native calls I would invoke an RPC stub from
> Ruby that will deliver a UDP packet with the native function name and
> parameters to a PThread that will in turn call the C function. Any result
> from C would be passed back to Ruby using the same channel, allowing the
> Ruby code to synchronize using traditional methods and avoid an utter
> threading mess.


Without knowing enough about your application, my reaction to your question
is this: it seems like you have plenty of good code already written in C for
handling what I assume are requests-for-service that come to you in UDP
packets. Why not wrap your C code in a Ruby extension (generally an easy
thing to do) and then have an EventMachine protocol handle simply call your
C code with the data from the sockets? That way your C code doesn't need to
know or care that network communications are even involved, and you can Ruby
to do all the format-massaging, which Ruby is really good at.

What's the execution profile of your C-code? Does it block locally on things
like database calls? If so, then you should use EM's patterns for deferred
execution. If not, then it's real easy and straighforward.

------art_20476_8158291.1159983820601--