skywind3000 wrote:
> I can sleep longer in timerjob.py, but I can't add a single sleep if I start 
> grep as a job. And I can't decide how long should I sleep to avoid dropping.

latest channel.txt said:
Note that if the job exits before you read the output, the output may be lost.
This depends on the system (on Unix this happens because closing the write end
of a pipe causes the read end to get EOF).  To avoid this make the job sleep
for a short while before it exits.

It is strange if a sleep is required in every command line utility, half of 
shell commands (with pipe) we used every day may break down.

I wrote another test to verify this issue:
the child process is repeating calling write
the parent process is repeating calling read & sleep

child process exits quickly, but we don't have any message dropped

--------------------
pipesleep.c
--------------------
#include <stdio.h> 
#include <string.h> 
#include <stdlib.h> 
#include <unistd.h> 
#include <sys/errno.h> 
#include <linux/fcntl.h> 
 
#define READ 0 
#define WRITE 1 
 
int main(void) 
{ 
    int fd[2], pid; 
    if (pipe(fd) < 0) {
        perror("pipe");
        exit(1);
    }
    if ((pid = fork()) == -1) {
        perror("fork");
        exit(1);
    }
    if (pid == 0) {     // child
        char text[100];
        int i;
        close(fd[READ]);
        for (i = 0; i < 2000; i++) {
            sprintf(text, "this is very loooooooooonnnnnnnnnnnnnnnnnnng line 
%d\n", i);
            write(fd[WRITE], text, strlen(text));
        }
        fprintf(stderr, "[child exit here]\n");
        fflush(stderr);
    }
    else {              // parent
        char text[100];
        int i;
        close(fd[WRITE]);
        for (i = 0; i < 10000; i++) {
            int hr = read(fd[READ], text, 100);
            if (hr <= 0) {
                printf("\n[done, errno is %d]\n", errno);
                break;
            }   
            else {
                text[hr] = 0;
                printf("%s", text);
                fflush(stdout);
            }
            usleep(10 * 1000);
        }
    }
    return 0;
}

------------------------
output of pipesleep.c
------------------------
this is very loooooooooonnnnnnnnnnnnnnnnnnng line 0
this is very loooooooooonnnnnnnnnnnnnnnnnnng line 1
this is very loooooooooonnnnnnnnnnnnnnnnnnng line 2
this is very loooooooooonnnnnnnnnnnnnnnnnnng line 3
this is very loooooooooonnnnnnnnnnnnnnnnnnng line 4
this is very loooooooooonnnnnnnnnnnnnnnnnnng line 5
this is very loooooooooonnnnnnnnnnnnnnnnnnng line 6
this is very loooooooooonnnnnnnnnnnnnnnnnnng line 7
this is very loooooooooonnnnnnnnnnnnnnnnnnng line 8
......
this is very loooooooooonnnnnnnnnnnnnnnnnnng line 829
[child exit here]
this is very loooooooooonnnnnnnnnnnnnnnnnnng line 830
this is very loooooooooonnnnnnnnnnnnnnnnnnng line 831
......
this is very loooooooooonnnnnnnnnnnnnnnnnnng line 1997
this is very loooooooooonnnnnnnnnnnnnnnnnnng line 1998
this is very loooooooooonnnnnnnnnnnnnnnnnnng line 1999

[done, errno is 0]
------------
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 ?


-- 
-- 
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.

Raspunde prin e-mail lui