Lcd wrote:
> On 8 February 2016, Bram Moolenaar <b...@moolenaar.net> wrote:
> >
> > Thanks for the feedback. I think it's time to sketch the upcoming work.
> > It appears some thought that sockets was the end of it, that's not so.
> >
> >
> > For jobs the most useful are probably:
> > - A deamon, serving several Vim instances, connect by socket.
> > - One server working with one Vim instance, asynchronously.
> > - A server performing some work for a short time, asynchronously.
> > - Running a filter, synchronously (existing functionality)
> >
> > A channel can communicate over:
>
> 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.
> > - A socket (what ch_open() currently does)
> > - A pipe (only possible with an associated job) connected to
> > stdin/stdout/stderr.
>
> 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.
> [...]
> > Some combinations are likely to be most useful. I heard some people
> > mention using a server over pipes to write a message to and call a
> > callback when the response is received. I assume this would work best
> > with NL separated messages.
> >
> > Using pipes only works when starting a job. Thus these are closely
> > coupled.
>
> As you say, getting a program's output with callbacks over pipes
> only works for jobs. The main applications to this are:
>
> (1) running something like make in background
> (2) running a slow linter in background.
>
> With (1) we care to be notified when make is done, and its exit
> code. We care about the output only if there have been errors (I'm
> simplifying, of course). We don't really care what's going on before
> make is finished.
>
> With (2) we care to be notified about lint messages as soon as the
> linter prints them, so that we can highlight syntax errors on the fly,
> and perhaps also update a quickfix list. That's the main point of
> having callbacks for the job's stdout and stderr. It's probably safe to
> assume the output to consist of lines of text.
>
> Both (1) and (2) are short-lived processes: they might be slow
> anough to make running them in foreground annoying, but we expect them
> to be finished (one way or another) when Vim exits.
>
> Starting a (presumably long-lived) server from Vim on the other hand
> is a very different animal. A server might print things like error
> messages before it goes to background. After that it isn't supposed
> to print anything or need output from stdin (doing that would rise a
> signal). A server in background is supposed to communicate with other
> processes only though a socket (INET, or UNIX domain).
Sure, different kind of jobs, but communication will mostly work the
same way.
> > Some parts that we still need that require some thougths:
> >
> > - Communicating over a socket requires knowing the port number. For a
> > deamon this would be a known number. For a server started by Vim it's
> > best to let the server pick an available port. Then how does it tell
> > Vim what port it picked? In test_channel we write the port number in
> > a file. That's not ideal, but perhaps there is no better solution.
> > Having Vim pick a free port and pass it to the server has race conditions
> > (but it might still be an acceptable solution).
>
> Communicating with a remote server requires a known address, and a
> known port. Remote servers are not started by Vim though.
>
> Servers started by Vim run on the local machine, and thus can use
> UNIX domain sockets instead of INET. A path pointing to an unique named
> pipe could be passed on to the server as a shared meeting point.
>
> > - When starting a job, where does it's stdin/stdout/stderr go?
> > Possibly the same terminal as Vim, a newly started terminal, a file or
> > /dev/null. No, running a terminal inside Vim is not an option. But
> > we could write stdout/stderr into a buffer.
>
> The answer depends on whether the job is a daemon, or a short-lived
> process. In the former case, as I said, we only need to catch messages
> at startup (after that stdin, stdout, and stderr should be closed).
>
> In the later case I think the output should go to the callback
> functions. Default callback function could just send everything to
> /dev/null. And if the user cares to print the output to the terminal
> she could override the callbacks with echo or echomsg. No need to make
> any special cases for it in Vim.
>
> A further difference between long-lived and short-lived processes is
> the way process groups are handled. For short-lived processes, the
> sequence should be something like this:
>
> - fork()
> - in the child: exec()
> - in the parent: install a SIGCHLD and waitpid()
>
> For daemons the sequence should be:
>
> - fork()
> - in the child: setsid(), fork() again, and exit
> - in the second child: exec()
> - in the parent: blocking waitpid().
>
> To kill the group of a daemon, you need to kill() the negated PID of
> the _first_ child, because that's the session leader.
>
> [...]
> > For {options} the main thing we're missing is what to do with
> > stdin/stdout/stderr:
> > "term": "pty" // use current terminal
> > "term": "open" // start a terminal
> > This would result in stdin/stdout/stderr to connect to the terminal,
> > unless specified otherwise. Except that reading from the current
> > terminal won't happen (Vim is reading that).
> [...]
>
> 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.
But like you say, many jobs would be completely silent, all output is
handled by handlers.
--
Spam seems to be something useful to novices. Later you realize that
it's a bunch of indigestable junk that only clogs your system.
Applies to both the food and the e-mail!
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--
--
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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
