In the linux tcp epoll mode, some conditions will lead to starvation when reading, as well as data loss and repeated sending problems in the buffer to be written in the connection

[zjs604381586]

The three questions are as follows:
1. When writing data to fd through the loopWrite function, you should check the number of successfully written bytes returned, because when writing some bytes successfully, if the write buffer of fd is full, err=syscall will also be returned .EAGAIN, which leads to repeated data writing next time. When the syscall.Write() function returns err, judge whether n is equal to -1, so as to slice the buffer of partially written data to avoid the next repetition Write.

2. When writing data to fd through the loopWrite function returns err=syscall.EAGAIN, call the Wake() function of conn to wake up the connection, wake up the Data() function of evio.Events in loopWake(), and return the data to be written to the connection, if the conn was previously .out has a buffer to be written, which will cause the previous buffer data in conn.out to be lost.

3. When writing data to fd through the loopWrite function returns err=syscall.EAGAIN, continue to call the Wake() function of conn to wake up the connection, wake up the Data() function of evio.Events in loopWake(), and return the large batch of data to be written by the connection, if The write buffer of fd has space to write. At this time, the fd is also triggered by a read event. When each epoll is triggered, only the loopWrite function will be processed, and err=syscall.EAGAIN will be returned when writing, which is the waiting time of fd. All data in the write buffer is not successfully written to fd, at this time the connection will be in a state of continuous writing, and each time epoll triggers the phenomenon that the connection read event is not processed, causing the fd read processing to starve .Note: This phenomenon should rarely happen, but I think it may happen if you do this

[woshihuo12]

same issue,can someone help?