the source of vimmake.6.cmd:
-----------------------
@echo off
python d:\acm\github\vim\tools\test.py
-----------------------
and the source of test.py:
----------------------
import sys
for i in xrange(30):
if i % 2 == 0:
sys.stdout.write('[%d]: stdout\n'%i)
sys.stdout.flush()
else:
sys.stderr.write('[%d]: stderr\n'%i)
sys.stderr.flush()
import time
time.sleep(1)
----------------------
[email protected]
From: [email protected]
Date: 2016-05-19 22:11
To: Bram Moolenaar
CC: vim-dev
Subject: Re: Re: job_stop is unusable in windows (gvim 7.4.1832) (2 bugs)
>> 'close_cb' and 'exit_cb' will not be invoked if I stop the job by
>> job_stop(s:job_obj, 'int') in windows.
> This is because on Windows we don't know the effect of sending 'int'.
> It basically sends a CTRL-C key. The process may do nothing with it.
thanks for reply, but in windows child process has already been stopped by
'int' signal,
but the following 'close_cb' or 'exit_cb' has never been invocated.
Seems vim doesn't know the child process has already been exited in windows
and still "looking for messages on channels"
here is my channel log:
==== start log session ====
16.528877 : Starting job: cmd.exe /C d:\acm\github\vim\tools\win32/vimmake.6
16.529539 on 0: Created channel
16.597577 : looking for messages on channels
16.800522 RECV on 0: '[0]: stdout
'
16.800562 on 0: Invoking channel callback g:Vimmake_Build_OnCallback
16.925442 : looking for messages on channels
17.748489 RECV on 0: '[1]: stderr
'
17.748529 on 0: Invoking channel callback g:Vimmake_Build_OnCallback
17.793600 : looking for messages on channels
18.727212 RECV on 0: '[2]: stdout
'
18.727251 on 0: Invoking channel callback g:Vimmake_Build_OnCallback
18.753327 : looking for messages on channels
19.745455 RECV on 0: '[3]: stderr
'
19.745493 on 0: Invoking channel callback g:Vimmake_Build_OnCallback
19.781825 : looking for messages on channels
20.753949 RECV on 0: '[4]: stdout
'
20.753980 on 0: Invoking channel callback g:Vimmake_Build_OnCallback
20.818269 : looking for messages on channels
21.751584 RECV on 0: '[5]: stderr
'
21.751617 on 0: Invoking channel callback g:Vimmake_Build_OnCallback
21.865572 : looking for messages on channels
22.731953 RECV on 0: '[6]: stdout
'
22.732024 on 0: Invoking channel callback g:Vimmake_Build_OnCallback
22.850624 : looking for messages on channels
23.772697 RECV on 0: '[7]: stderr
'
23.772735 on 0: Invoking channel callback g:Vimmake_Build_OnCallback
23.889643 : looking for messages on channels
24.785400 RECV on 0: '[8]: stdout
'
24.785437 on 0: Invoking channel callback g:Vimmake_Build_OnCallback
24.851843 : looking for messages on channels
25.058043 on 0: Stopping job with 'int'
25.078212 RECV on 0: 'Traceback (most recent call last):
File "d:\acm\github\vim\tools\test.py", line 11, in <module>
time.sleep(1)
KeyboardInterrupt
'
25.078232 : looking for messages on channels
25.078273 on 0: Invoking channel callback g:Vimmake_Build_OnCallback
25.089159 on 0: Invoking channel callback g:Vimmake_Build_OnCallback
25.099039 on 0: Invoking channel callback g:Vimmake_Build_OnCallback
25.104338 on 0: Invoking channel callback g:Vimmake_Build_OnCallback
25.211838 RECV on 0: 'Terminate batch job (Y/N)? '
25.211873 : looking for messages on channels
------------
that's all of the channel log, cannot find any 'close_cb' and 'exit_cb' in 10
minutes after job stopped.
[email protected]
From: Bram Moolenaar
Date: 2016-05-19 20:58
To: [email protected]
CC: vim-dev
Subject: Re: job_stop is unusable in windows (gvim 7.4.1832) (2 bugs)
Skywind wrote:
> ------------------ BUG 1 ---------------------
> job_stop will not actually stop the process in windows unless I unlet the job
> variable
>
> step to reproduct (windows gvim 7.4.1832):
> 1. start a background python job (output a single line and sleep 1 second,
> repeat 30 times)
> 2. redirect stdout/stderr into quickfix window by 'callback'
> 3. call job_stop with 'term' or 'kill' and ** DO NOT unlet job object **
> 4. check job_status and it changed from 'run' to 'dead'
> 5. ERROR: but the job is still running, still output text to quickfix window
> 6. when it actually exit by it self (after repeat itself 30 times) 'close_cb'
> and 'exit_cb' were invoked
>
> and if I unlet job object after job_stop, everything seems okay, the job can
> actually be stopped
> but job object can not be unleted after job_stop, because sometimes child
> process will stop signal from
> being terminated (ignore TERM etc) in this circumstance, if I immediately
> unlet job object after
> a no-effect job_stop calling my script will fail into an error environment.
>
> This is only in windows, in linux everything is fine, I can clean the job
> object in exit_cb/close_cb as my wish.
> and job_stop doesn't require a unlet in linux too.
I'll put this in the todo list. It would be useful to have a channel
log for this example.
> ------------------ BUG 2 ---------------------
> 'close_cb' and 'exit_cb' will not be invoked if I stop the job by
> job_stop(s:job_obj, 'int') in windows.
>
> if 'term', 'kill' were used to stop the child process (s:job_obj must be
> unlet after it due to bug 1),
> 'close_cb' and 'exit_cb' will be invoked correctly.
>
> But 'close_cb' and 'exit_cb' can be lost if 'term', 'kill' has been replaced
> to 'int'.
This is because on Windows we don't know the effect of sending 'int'.
It basically sends a CTRL-C key. The process may do nothing with it.
> These two bugs are ONLY in windows (gvim 7.4.1832),
--
ARTHUR: What are you going to do. bleed on me?
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- [email protected] -- 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 [email protected].
For more options, visit https://groups.google.com/d/optout.
