On 09-Feb-16, Bram Moolenaar wrote:
>
> Olaf Dabrunz wrote:
>
> > 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.
>
> I don't think that works. If Vim keeps the socket open the server can't
> open it again, gives an "already in use" error.
James already answered it, more concisely.
My mid-air collision version, and longer...:
The socket descriptor opened in Vim will be inherited to the child
process, the server. The child process / server does not need to
re-open it, it simply uses the already open descriptor. (Trying to
re-open the socket would indeed give "already in use".)
The parent process (Vim) closes its copy of the socket descriptor after
the fork because it does not need the listening socket, and because the
socket should really shut down whenever the child (the server) closes it.
Inheriting the descriptor of the listening socket is done regularly in
pre-forked multiprocess servers.
The "prefork" bullet summarizes it:
http://freeprogrammersblog.vhex.net/post/linux-39-introduced-new-way-of-writing-socket-servers/2
> > > 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
>
> Unfortunately that doesn't work. I used that in the test at first:
>
> let job = job_start(['/bin/sh', '-c', 'python test_channel.py
> </dev/null >/dev/null'])
> call getchar()
> call job_stop(job)
>
> While it's waiting for a character, check the processes. You should see
> both the shell and the python process. After pressing Enter the shell
> is gone but the python process keeps running. At least on my Ubuntu
> system.
Ah right, you already use this in 7.4.1274.
To correct myself: kill the negative of the PID of the session leader,
this sends the signal to all processes in its process group (!), see
kill(2):
mch_stop_job():
sig = atoi((char *)how);
else
return FAIL;
- kill(job->jv_pid, sig);
+ kill(-job->jv_pid, sig);
return OK;
}
#endif
This also triggers a sort of chain reaction that should bring down the
other process groups in the session (if any), unless they ignore SIGHUP:
When the session leader exits, all processes in the foreground
process receive a SIGHUP.
When the parent (typically the session leader) of a background
process group with at least one stopped process exits, all processes
in that background process group receive a SIGHUP. (And a SIGCONT,
which makes them continue running in the background in case they
ignore SIGHUP.)
See more details in
- http://www.win.tue.nl/~aeb/linux/lk/lk-10.html#ss10.3
- man 2 setpgid
--
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.
