On 09-Feb-16, Bram Moolenaar wrote:
> Can you try again after the change I just sent out? Patch 7.4.1294.
Olaf Dabrunz wrote:
> In-Reply-To: <2016020915...@santana.dyndns.org>
>
> On 09-Feb-16, Bram Moolenaar wrote:
> >
> > Manuel Ortega wrote:
> >
> > > On OS X 10.11.3, the 'make test' step runs tests of the new channel stuff.
> > > By looking at Activity Monitor.app, this opens at least three processes
> > > called "python2.7". At least one of them is quickly quit, but two remain
> > > running even after the 'make test' has completed running.
> > >
> > > I first noticed this because there were about 15 or 20 such processes
> > > running. I had built and tested Vim several times since my last login, and
> > > all those pythons were left up.
> > >
> > > This is reproducible every time.
> >
> > Can you try again after the change I just sent out? Patch 7.4.1294.
>
> It may also be necessary to start the server with "exec", so it uses the
> process group of the shell.
The command used is:
let s:job = job_start("python test_channel.py")
It's not using a shell, only starts the python process. Is that correct
Manuel, you only see one kind of process?
ch_open('localhost' . s:port) fails by timeout, so s:start_server() returns (channel)-1 and s:kill_server() doesn't execute.
patch:
I propose to use try-finally to execute s:kill_server().
https://gist.github.com/ichizok/3820b16b7198847e75c7
And, on OS X, ch_open() needs option waittime > 0 to pass test_channel.
patch:
use waittime option
https://gist.github.com/ichizok/30ae71b0e12b85a1f864
Thank you.
- Ozaki Kiichi
Ozaki Kiichi wrote:
> I checked test_channel.vim on OS X 10.11.3;
>
> ch_open('localhost' . s:port) fails by timeout, so s:start_server()
> returns (channel)-1 and s:kill_server() doesn't execute.
>
> patch:
> I propose to use try-finally to execute s:kill_server().
> https://gist.github.com/ichizok/3820b16b7198847e75c7
>
> And, on OS X, ch_open() needs option waittime > 0 to pass test_channel.
>
> patch:
> use waittime option
> https://gist.github.com/ichizok/30ae71b0e12b85a1f864
Thanks, I'm glad you could solve this mystery.
I do wonder why a 1 msec waittime makes it work, it probably means there
is something wrong with what happens with the zero waittime.