Re: How to communicate with a running external process with

[Thorsten Jolitz]

Yuri Khan <yuri.v.khan@gmail.com> writes:

> On Tue, Jul 23, 2013 at 2:59 PM, Thorsten Jolitz <tjolitz@gmail.com> wrote:
>
>> Assume there are 2 otherLisp processes up and running and 2 Emacs
>> processes, and you want to communicate from otherLisp with PID 5555 to
>> Emacs with PID 6666.
>
> First, decide which program is the server and which is the client. A
> server, roughly speaking, is the process that first establishes the
> channel of communication — creates a pipe, a Unix socket, or listens
> on a TCP port. Clients then have to know the pipe path/filename, the
> Unix socket path, or the IP address and TCP port, in order to connect
> to the server. Once the connection by client is established, both
> server and client have a file descriptor and can communicate just by
> writing into it.
>
> If you have two instances of the server, they have to listen on
> different pipes, Unix sockets (by path/name), or, in case of TCP, the
> <IP address:port> pairs have to be distinct. Thus, the clients will be
> able to connect to the server they want, by knowing the specific
> server pipe or Unix socket path or IP address and TCP port.
>
> The process ID just never enters the picture. (Although, if you
> control the server, you can make up a convention that, e.g., the
> server always listens on the Unix socket with the path
> /var/run/your_server_name.$PID.)

ok, I think now I get it - just like starting a TCP server and then
accessing its <IP address:port> , the otherLisp (as a server) has to
open a pipe or socket first (which do have a path/filename), and knowing
the path/filename I can access that otherLisp process that acts as a
server from an Emacs Lisp program.

Vice versa it should be possible to open a pipe or socket from Emacs
Lisp (without starting a subprocess of otherLisp), and connect to it
from otherLisp using the specific path/filename.

I think I have to take a second look at the manuals wrt this idea. So in
both Lisp dialect there should be a way to open a pipe or socket, return
the path/filename of it, and keep listening for incoming connections
until it is closed. Thanks for the tips. 

-- 
cheers,
Thorsten