The application I'm using this for is simulating a small system (embedded CPU) which just happens to be in C. The nodes are connected together with radios (think Crossbow or Dust Systems), and I'd like to simulate a network of them, while letting the Ruby code record the radio traffic to a database for later analysis. When they make a call to their "Send a radio message" routine, I just catch that in the Ruby and then deliver it to whatever nodes are "close enough" to hear it. I think I can make it work using the FFI and call-backs. I've found that I can use the library approach if I make a discrete copy of the library for each node; each will get mapped into the space independently. The global variables don't clash because all the linking is done at runtime; I'm not sure exactly how it works, but it appears that the global vars are not added to the processes global vars, at least as far as I can tell.
My other choice would be to use something like DRB to make it possible to run the many processes.
On Sat, Nov 20, 2010 at 5:01 PM, Chuck Remes
<cremes.devlist@mac.com> wrote:
On Nov 20, 2010, at 10:04 AM, Kim.Toms wrote:
> I'd like to load the same library multiple times, so that the global
> variables in my C program are complete separate. This would allow me
> to run multiple simulations of objects that arre connected. The
> objects are all communicating with each other, and I'd like to track
> the communication. I've posted a simple example in the issues at
>
https://github.com/ffi/ffi/issues/#issue/65
I don't think this is possible. When you load a library, it is mapped into the same address space as the interpreter (MRI, JRuby, Rubinius, etc.). If your library is using global variables in a global namespace, then it isn't re-entrant either.
I recommend modifying the library so it is re-entrant. Then you can load the library *once* but call into it from multiple threads safely.
cr