Daniel Hahler wrote:
> > Thanks, this is useful. Now we need to find out why we see an error or
> > nothing to read, while reading the pipe/socket should give us the
> > output. Adding some ch_logs() calls in channel_wait() could help
> > pinpoint it.
>
> Sorry, I have not patched/debugged Vim, but want to add some findings while
> trying to make the async support for Vim work in Neomake.
>
>
> I think this might also be related to channels only being read from
> when Vim waits for user input, and that the closing callback is being
> invoked nonetheless - but input is discarded?!
>
> The following will not collect the line (to be run with `vim -Nu t.vim`):
>
> ```
> call ch_logfile('/tmp/job.log')
>
> let g:lines = []
> function Callback(channel, data)
> echom "CALLBACK" string(a:channel) string(a:data)
> echom "\n"
> let g:lines += [a:data]
> endfunction
>
> function Close_cb(channel)
> let g:lines += ['closed']
> echom "CLOSE" string(a:channel)
> echom "\n"
> endfunction
>
> function Start(nr)
> return job_start(['sh', '-c', 'echo '.a:nr], {
> \ 'callback': 'Callback',
> \ 'close_cb': 'Close_cb',
> \ })
> endfunction
>
> call Start(1)
> sleep 1
> echom "lines" string(g:lines)
> ```
When I run this, the output is:
lines []
Press ENTER or type command to continueCALLBACK channel 0 closed '1'^@CLOSE
channel 0 closed^@
And g:lines contains: ['1', 'closed']
So the output is read correctly, but only after "sleep 1".
> I can make it work when using `call input('continue?')` instead of the sleep.
What do you mean with "can make it work"?
> Is there another workaround / command that can be used to read from
> all channels?
>
> Callbacks are only called at a "safe" moment, usually when Vim
> is waiting for the user to type a character. Vim does not use
> multi-threading.
>
> The workaround I've found to make the tests in Neomake work is appending a
> "sleep .1" to the job's (shell) command: this makes it apparently stay long
> enough so that output gets handled. But I do not think this is a good
> workaround after all, and it does not work when trying to call "nonexistent".
>
>
> For starters: what about handling "sleep" like "call input()"?
Yes, I thought that already happened, apparently not.
> btw: I've found that `ch_read(job, {'timeout': 0})` can be used to read from
> the channel, but that does not trigger the callbacks, and the following will
> even deadlock Vim (100%), apparently in "ch_read":
>
> ```
> let job = Start(1)
> while 1
> let job_info = job_info(job)
> if job_info['status'] == 'dead'
> let data = ch_read(job, {'timeout': 0})
> echom "READ DATA" string(data)
> endif
> echom string(job_info)
> echom "."
> sleep 10m
> endwhile
> echom "lines" string(g:lines)
> ```
>
> The log for this is:
> 0.000040 : Starting job: sh -c echo 1
> 0.000076 on 0: Created channel
> 0.012068 : looking for messages on channels
> 0.012367 on 0: Job ended
> 0.012836 on 0: Blocking NL read, timeout: 0 msec
> 0.012994 RECV on 0: '1
> '
> 0.013014 on 0: Returning 1 bytes
> 0.023729 : looking for messages on channels
> 0.024069 on 0: Blocking NL read, timeout: 0 msec
> 0.024097 ERR on 0: channel_read_block(): Cannot read from channel, will
> close it soon
>
>
> Sorry for the unstructured comments, but it appears to be really buggy
> in this regard.
Mixing callbacks with reading with ch_read() creates a race condition,
better not do that.
--
[clop clop]
ARTHUR: Old woman!
DENNIS: Man!
ARTHUR: Man, sorry. What knight lives in that castle over there?
DENNIS: I'm thirty seven.
ARTHUR: What?
DENNIS: I'm thirty seven -- I'm not old!
The Quest for the Holy Grail (Monty Python)
/// 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.
