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. > > - 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 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. -- hundred-and-one symptoms of being an internet addict: 194. Your business cards contain your e-mail and home page address. /// 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.
