On 9 February 2016, Bram Moolenaar <[email protected]> wrote:
>
> Lcd wrote:
[...]
> > I don't really understand what problem do channels solve, or
> > where is all this heading. Thus I'll refer mostly to jobs below,
> > and I'll comment only on a few implementation details for channels.
>
> Jobs are processes, channels are a way to communicate. I don't see
> how you can have jobs and not communicate with them in a useful way.
I'm afraid I still don't get it. With jobs Vim can communicate
with processes that aren't specifically aware they are talking to Vim.
It can do that by opening pipes for the jobs' stdin and stdout. If
it needs to give them "wheels" (that is, communicate with processes
on another machine), this can be done with UCSPI. This is a solved
problem, and the common solutions such as UCSPI can do things like
connect over TLS (and actually get it right), and do fancy TCP window
scaling and error recovery.
On the other hand, there are daemons that do things like parse a
source tree in background and can be queried about it over a socket.
But these daemons have their own APIs, and are not specifically prepared
to talk to Vim. Making Vim able to talk to them would require some kind
of adapter, which might be a job started by Vim. But then the burden
of handling protocols, TCP, and so on would be on the adapter. Vim
could still talk to the adapter through pipes to the adapter's stdin
and stdout. But the adapter would have to be written specifically for
the particular daemon, and there's no way around that. If Vim is to
talk directly to the daemon, without the adapter, then JSON or protocol
buffers are either too much, or too little. I can't see how channels
(as they are now) can fit into this picture. _shrug_
[...]
> > There are also UNIX domain sockets (a.k.a. named pipes), which
> > you get essentially for free once you have the code for INET
> > sockets. They are as efficient as (unnamed) pipes. The code is
> > already there, but it's mutually exclusive with INET sockets. I
> > don't think there is any reason why the two can't coexist as
> > separate mechanisms.
>
> We can support that later. As far as I know the main difference is
> how you connect, after that it's basically the same. Since we are
> using the netbeans code it uses sockets.
The main advantage over INET is that with UNIX sockets can choose
the rendezvous point, and pass it to the daemon on the command line (or
whatever). With INET it's the daemon that gets to choose the port, and
it has to find a way to pass it back to Vim.
[...]
> > Why is it important for the job to be able to access a pty?
>
> Not important. We do need the I/O to go somewhere. Main problem is
> input, if the job tries to read from the same terminal Vim will stop
> working. But output could go to the same place. Might mess up the
> display. So, normally "pty" means you have to setup the callbacks and
> everything to make it work, while "open" would have the job happily
> use some terminal. That would be required if the job has to prompt
> for anything, or display progress.
[...]
I don't think a job's input can be allowed access to Vim's tty,
ever. There are two main cases here: programs that don't need any
input, and are happy with command line options; and programs that need
to read things from stdin. In the first case there's no problem to
solve. It's the second case that's interesting, and there Vim could
either use another callback for the job's stdin to feed it data as
the job requests, or simply let it read from a file. The callback is
problematic, because it can run into deadlocks with the callbacks for
output (this is a well-known hard problem). Reading from a file is
safe, but limits what the job can do.
/lcd
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
