What are the possibilities in ruby for passing information from one
process to another? Specifically, I’m thinking of messaging between a
parent process and its forked child.
Right now I can think of some messaging primitives:
TCPServer/TCPSocket
UNIXServer/UNIXSocket (unstable?)
IO.pipe (doesn’t need port#)
Process.kill (impossible to send data)
And some messaging libraries:
DRb (standard)
eventmachine (efficient?)
…what else? And, if anyone has the experience, what are the
advantages/disadvantages of each in terms of speed, reliability, system
resources?
Am Wed, 10 Oct 2007 16:11:15 +0900
schrieb Daniel DeLorme [email protected]:
And some messaging libraries:
DRb (standard)
eventmachine (efficient?)
…what else? And, if anyone has the experience, what are the
advantages/disadvantages of each in terms of speed, reliability,
system resources?
Thanks,
Daniel
shared memory?
I don’t expect UNIXSocket to be unstable. I’m running over 2 years
with using ruby’s socket library without problems. Dont forget to
remove the created socket if your process ends
…what else? And, if anyone has the experience, what are the
advantages/disadvantages of each in terms of speed, reliability, system
resources?
Intramachine messaging with any of the technologies you mentioned will
be
pretty lightweight. The usual thing one tries to do with related
processes
is to open a pipe or a socketpair in the parent. Then after the fork,
just
send data over the sockets.
What are the possibilities in ruby for passing information from one
process to another? Specifically, I’m thinking of messaging between a
parent process and its forked child.
shared memory?
Is there a ruby lib to handle shared memory? Also, I can see how it can
be used for “passing information”, but for messaging between processes
wouldn’t it require constant polling to check if a message is waiting in
the shared memory?
I don’t expect UNIXSocket to be unstable. I’m running over 2 years
with using ruby’s socket library without problems. Dont forget to
remove the created socket if your process ends
I just vaguely remember reading in some mailing list or blog something
along the lines that “unix domain sockets are flaky”. I might have
misunderstood.
On Oct 10, 2007, at 9:39 AM, M. Edward (Ed) Borasky wrote:
So I’d go with EventMachine, because that is well maintained.
I would go with a pipe, because it’s easy and sounds like it’s all
that’s needed here. I’m an EventMachine fan, but don’t underestimate
the trivial approach.
Well, if the architecture is always going to be “parent-forked child
message passing on a single machine”, sure. But what if the task grows
beyond the capabilities of that architecture? Remember, I’m one of those
people who’s in favor of “premature” optimization.
But seriously, Ruby has so many user-friendly ways to do concurrency
both inside a single machine and across machines that I wouldn’t limit
myself to parent-forked child message passing on a single machine. I’d
use EventMachine because it’s more flexible. And to the person who
suggested “shared memory”, I’d say simply, “Bah!”
Intramachine messaging with any of the technologies you mentioned will be
pretty lightweight. The usual thing one tries to do with related processes
is to open a pipe or a socketpair in the parent. Then after the fork, just
send data over the sockets.
There’s also a Ruby MPI binding, but I’m not sure how well maintained it
is. I had trouble tracking it down on the web. So I’d go with
EventMachine, because that is well maintained.
On Wed, 10 Oct 2007 16:11:15 +0900, Daniel DeLorme wrote:
What are the possibilities in ruby for passing information from one
process to another? Specifically, I’m thinking of messaging between a
parent process and its forked child.
It may be a bit heavyweight for what you want, but there’s
ActiveMessaging:
On Oct 10, 2007, at 1:11 AM, Daniel DeLorme wrote:
And some messaging libraries:
DRb (standard)
eventmachine (efficient?)
…what else? And, if anyone has the experience, what are the
advantages/disadvantages of each in terms of speed, reliability,
system resources?
Thanks,
Daniel
this is, by far, the easiest approach - it addresses exactly your
problem by sticking a drb server in a forked child. the child has
arrangements made such that it can never outlive it’s parent:
I don’t expect UNIXSocket to be unstable. I’m running over 2 years
with using ruby’s socket library without problems. Dont forget to
remove the created socket if your process ends
Ditto. I’ve been using DRb over UNIX sockets extensively for about 2
years, and no problems here. Data volume and rate tend to be small in my
case, though.
…what else? And, if anyone has the experience, what are the
advantages/disadvantages of each in terms of speed, reliability,
system resources?
DRb will cause you to do the least amount of work. You only need to
speak ruby, you don’t need to do any serializing of data because it
all gets handled for you.
got a method of communicating a sequence of binary digits
to another process. If you’ve got a reasonably accurate
way of timing things you could just manage this with a single
signal because the absence of the signal could be detected.
I smell a ruby quiz: implement drb messaging on top of sigusr[12].
On Oct 10, 2007, at 5:03 PM, Joel VanderWerf wrote:
to another process. If you’ve got a reasonably accurate
way of timing things you could just manage this with a single
signal because the absence of the signal could be detected.
I smell a ruby quiz: implement drb messaging on top of sigusr[12].
Hmm. It would be difficult. Since signals are not reliable
in general, you would probably first have to construct the
equivalent of TCP/IP across signals. Drb messaging should be
easy after that…
Right now I can think of some messaging primitives:
TCPServer/TCPSocket
UNIXServer/UNIXSocket (unstable?)
IO.pipe (doesn’t need port#)
Process.kill (impossible to send data)
Not that it would be useful but I guess that if you used
two different signals (say SIGUSR1 and SIGUSR2) then you’ve
got a method of communicating a sequence of binary digits
to another process. If you’ve got a reasonably accurate
way of timing things you could just manage this with a single
signal because the absence of the signal could be detected.
Not that it would be useful but I guess that if you used
Unixes, they’re heavyweight (resource intensive), and they have
difficult
APIs.
I guess I should have added some smiley faces.
There is a whole area of computer security though, covert
signaling methods, where low bandwidth, unreliable communication paths
are still of interest.
On Fri, 12 Oct 2007 00:17:11 +0900, Gary W. wrote:
I guess I should have added some smiley faces.
There is a whole area of computer security though, covert
signaling methods, where low bandwidth, unreliable communication paths
are still of interest.
I got the joke…
I assumed it was a takeoff on “Process.kill (impossible to send data)”.
two different signals (say SIGUSR1 and SIGUSR2) then you’ve
got a method of communicating a sequence of binary digits
to another process. If you’ve got a reasonably accurate
way of timing things you could just manage this with a single
signal because the absence of the signal could be detected.
There’s some cleverness to this idea but I would avoid it. Signals
interact
very badly with threads and other system facilities, they’re not
deterministic, they have serious platform dependencies among different
Unixes, they’re heavyweight (resource intensive), and they have
difficult
APIs.
The OP simply wants to pass data back and forth between a process and
its
forked child. Socketpair or pipe is the orthodox (and the simplest) way
to
do this.
There is a whole area of computer security though, covert
signaling methods, where low bandwidth, unreliable communication paths
are still of interest.
