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.
Hmm, OK. But that only works for a process that was specifically written to do this. Not something that takes a --port argument. Also, how does the child process know which file descriptor has the socket? For example, how would this work with the demo server? Does this work for MS-Windows? Probably not, since it doesn't use fork(). > 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 Ah, forgot about that way. It's actually in os_unix.c. > 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 So, should we do this always or make it an option? I think we should make this the default and have an option to only kill the process itself. Although the child of the child could use setsid() if it doesn't want to be killed. -- % cat /usr/include/sys/errno.h #define EPERM 1 /* Operation not permitted */ #define ENOENT 2 /* No such file or directory */ #define ESRCH 3 /* No such process */ [...] #define EMACS 666 /* Too many macros */ % /// 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.
