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

On 10/11/07, Gary Wright <gwtmp01 / mac.com> wrote:
>
>
> On Oct 10, 2007, at 6:04 PM, Francis Cianfrocca wrote:
> > 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.
>
> 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.
>
>
You got me. I am PWNED!

:-)

------art_25707_14172670.1192127241067--