Hi Bram,
2016/2/25 Thu 5:56:12 UTC+9 Bram Moolenaar wrote:
> Yukihiro Nakadaira wrote:
>
> > > > On Wed, Feb 24, 2016 at 8:11 PM, mattn <[email protected]> wrote:
> > > >
> > > > > I'm thinking "kill" is not matter for this test because this test
> > > should
> > > > > be checking of exit.
> > > > >
> > > > > diff --git a/src/testdir/test_channel.vim
> > > b/src/testdir/test_channel.vim
> > > > > index 69922b1..e74e54c 100644
> > > > > --- a/src/testdir/test_channel.vim
> > > > > +++ b/src/testdir/test_channel.vim
> > > > > @@ -483,6 +483,7 @@ func Test_exit_callback()
> > > > > if has('job')
> > > > > call s:run_server('s:test_exit_callback')
> > > > >
> > > > > + call job_stop(s:exit_job, "kill")
> > > > > " the job may take a little while to exit
> > > > > sleep 50m
> > > > >
> > > >
> > > > In CUI Vim, job_stop(job, "hup") doesn't work because AttachConsole()
> > > fails.
> > > > The following patch might fix it. Job process is created in same
> > > console.
> > > > I'm not sure if it doesn't causes another problem.
> > >
> > > There is a todo item to make it possible to start a terminal for the job
> > > to run in. This is especially useful if the job produces some output
> > > and perhaps even prompts for input. We don't want that to get mixed up
> > > with the Vim display.
> > >
> > > So hopefully we can make both work. This would require the job to be
> > > started with a socket, so its stdin/stdout go to the terminal.
> > >
> >
> > I see. So "kill" is a simple solution.
>
> I'm wondering, if this test fails because the job didn't finish yet,
> don't we have the same problem with every other test, since they all
> start the server?
Yes, you are right.
When running test_channel.vim on Win32 CUI, many python processes are left.
> It seems that the default behavior for mch_stop_job() is being too
> gentle. And it only has "kill" and everything else. And that means
> sending CTRL_C_EVENT or CTRL_BREAK_EVENT.
>
> Perhaps we should make the default behave like "kill" and only have
> "hup" and "int" send an event? The default is actually supposed to be
> the same as "term", which for MS-Windows probably is the same as "kill".
I wrote a patch to change the default to "kill" on Windows. Other behaviors are
not changed. With this patch, no python processes are left, and of cause
the test_channel.vim passes.
Regards,
Ken Takata
--
--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
# HG changeset patch
# Parent 34e55cf88be6d4dfff3f45f7d702b58afc2957d4
diff --git a/runtime/doc/eval.txt b/runtime/doc/eval.txt
--- a/runtime/doc/eval.txt
+++ b/runtime/doc/eval.txt
@@ -4474,21 +4474,22 @@ job_status({job}) *job_status()* *E9
job_stop({job} [, {how}]) *job_stop()*
Stop the {job}. This can also be used to signal the job.
- When {how} is omitted or is "term" the job will be terminated
- normally. For Unix SIGTERM is sent. For MS-Windows
- CTRL_BREAK will be sent. This goes to the process group, thus
- children may also be affected.
+ When {how} is omitted the job will be terminated normally on
+ Unix. On MS-Windows the job will be terminated forcedly.
+ This goes to the process group, thus children may also be
+ affected.
Other values for Unix:
- "hup" Unix: SIGHUP
- "quit" Unix: SIGQUIT
- "kill" Unix: SIGKILL (strongest way to stop)
- number Unix: signal with that number
+ "term" SIGTERM (default)
+ "hup" SIGHUP
+ "quit" SIGQUIT
+ "kill" SIGKILL (strongest way to stop)
+ number signal with that number
Other values for MS-Windows:
- "int" Windows: CTRL_C
- "kill" Windows: terminate process forcedly
- Others Windows: CTRL_BREAK
+ "kill" terminate process forcedly (default)
+ "int" CTRL_C
+ Others CTRL_BREAK
On Unix the signal is sent to the process group. This means
that when the job is "sh -c command" it affects both the shell
diff --git a/src/os_win32.c b/src/os_win32.c
--- a/src/os_win32.c
+++ b/src/os_win32.c
@@ -5149,7 +5149,7 @@ mch_stop_job(job_T *job, char_u *how)
int ret = 0;
int ctrl_c = STRCMP(how, "int") == 0;
- if (STRCMP(how, "kill") == 0)
+ if (STRCMP(how, "kill") == 0 || *how == NUL)
{
if (job->jv_job_object != NULL)
return TerminateJobObject(job->jv_job_object, 0) ? OK : FAIL;
