From: Francis Cianfrocca <garbagecat10@...>
Date: 2007-10-11T07:04:57+09:00
Subject: Re: Inter-Process Messaging

------=_Part_21520_27396575.1192053898356
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 10/10/07, Gary Wright <gwtmp01@mac.com> wrote:
>
>
> Daniel DeLorme wrote:
> > 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.



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.

------=_Part_21520_27396575.1192053898356--