2016-11-30 19:06 GMT+09:00 skywind3000 <[email protected]>: > skywind3000 wrote: > > > we can see: > > > > 1. there is a "sleep" in the parent process, parent works slower than > child. > > > > 2. calling "write" block the child process successfully when pipe is > full (4096 bytes on linux by default). The child process does not exit > immediately. > > > > 3. 10 seconds later after child process exist, we can still read > messages from the parent process. > > > > This is exactly the right behavior of inter-processes communication. > > > > Since we can't add a sleep in grep, tail, less, more, cut..... and we > don't know how long should we sleep either. > > > > How can we prevent message dropping when we are using ch_read ? > > I can reproduce it with popen in python: > -------------- > parent.py > -------------- > import sys, os, time > > fp = os.popen('python child.py', 'r') > > while 1: > text = fp.readline() > if text == '': > break > print text.rstrip() > sys.stdout.flush() > time.sleep(0.001) > > ------------ > child.py > ------------ > #! /usr/bin/env python2 > import sys, time > > t = time.time() > for i in xrange(20000): > sys.stdout.write('timer job: this is line %d\n'%(i)) > sys.stdout.flush() > > t = time.time() - t > print '[done in %d seconds]'%int(t) > > # as channel.txt said, we need a sleep here > time.sleep(1) > > ---------------- > reproduce > ---------------- > $ python parent.py > timer job: this is line 0 > timer job: this is line 1 > timer job: this is line 2 > ..... > timer job: this is line 19996 > timer job: this is line 19997 > timer job: this is line 19998 > timer job: this is line 19999 > [done in 21 seconds] > > ------------- > 1. there is a sleep in parent.py, parent works slower than child too. > 2. the child.py can be blocked successfully by parent.py > 3. no sleep in child.py > 4. no message dropped. > > it behaves the same way just like the c version in my previous post. >
Looks you are trying to simplify the issue too much. Your argument looks good for utilities such as grep, tail, cut and so on. However, Vim (or any other programs having UI which is driven by events) is different from them in that, while Vim is made busy to handle a deluge of input from an external program, it also has to ask the terminal or the GUI to update its contents simultaneously (in appearance, at least). Actually, the event loop cannot handle the both tasks simultaneously; it tries to do only one thing when select() or poll() is called, and it can execute a thing only after it makes sure another is staying idle at that time. IOW, an illusion that both external input handling and UI update appear to happen simultaneously is made possible only if both of them can stay idle alternatively. The GUI will be locked if it is not given a chance to run the event loop for its own sake. The third element UI makes your issue very tough, and that issue itself is inherently difficult; while the user is asking an external program to do its job asynchronously, he is also asking Vim to show the result as if they were working synchronously, using the UI which inherently works asynchronously. A awful set of simultaneous equations. That said, I never mean that any effort done here so far doesn't make sense. Actually, I already enjoy the fruit; as far as the examples skywind3000 raised (except the one after 8.0.105) are concerned, the issue appears to be fixed for me. > > -- > -- > 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. > -- -- 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.
