Serge Kruppa
10/5/2006 12:14:00 PM
>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.
An issue we have is that all our code must run in an embedded Ruby
environment (Active Ruby), packaged as a traditional Windows application
(MFC). Ruby is the hidden jewel inside a fairly standard Windows program. If
I understood your suggestion correctly, the idea would be to layer an
EventMachine on top of our C code already packaged as a Ruby extension. The
EM would act as a UDP event-driven middleware, passing function requests and
responses back and forth between our main Ruby program and the C code? How
do you suggest we interface the EM with the main Ruby program?
Our Ruby program structure is not event driven unfortunately. I did convert
during the night the C native function that invokes the Ruby callbacks to a
simple UDP message send with a specially formatted text string containing
the parameters. The EM receives these UDP callback notifications very
effectively and passes them on to actual Ruby Proc objects for further
processing.
However, taking the example of my unit test suite, I'm using a simple fall
through logic of test cases executed in logical sequence. I found it
impossible to naively insert the EM into my test suite (I'm ashamed to admit
that I tried to run the EM within a Thread, which resulted in the EM
catching only the first UDP callback and missing all the subsequent ones).
Regarding your question about the execution profile of our C code, it is
mostly RPC style: one computer sends a request to another and blocks on a
PThread condition variable until a response is received from the other end
or a timeout occurs. We do have database operations as well, protected by a
series of PThread mutexes.
I have been looking for more information about the EM deferred execution
pattern but did not find any straightforward description. Any pointers to
suitable Web pages would be most appreciated :)