On 08-Feb-16, Bram Moolenaar wrote:
> 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).

To avoid the race, Vim could open the server's listening socket before
forking off the server, then close the socket descriptor on Vim's side.

> - 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.

It seems most useful to open pipe()s in Vim that connect the job's
stdin/stdout/stderr back to Vim.  This makes it easy to use simple
programs in filter jobs and server jobs with a single client.

This seems to be amongst the options you describe below.  I do not come
up with an example where direct connection to the terminal is useful.

For multi-client daemon jobs, the stdout and stderr should probably go
to a log file, and stdin should be connected to /dev/null.  This and
double-forking with setsid() in between also creates a daemon that is
not associated to a controlling terminal, so that user signals on a
terminal (Ctrl-C) are not accidentally sent to it.

    http://stackoverflow.com/questions/3095566/linux-daemonize

Not sure what to do on Windows though.

> One problem that I haven't figured out yet: When starting a job using a
> shell, we get the PID of the shell.  So we can kill the shell, but not
> the process that it started. 

Put the shell in a new session with setsid().  Killing all processes in
the session is done by sending the signal to the session leader (here:
the shell).

Similar to daemon-izing a job.

    http://www.win.tue.nl/~aeb/linux/lk/lk-10.html#ss10.3

-- 
Olaf Dabrunz (oda <at> fctrace.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.

Raspunde prin e-mail lui