Write operation principle, error cause and solution in linux

In linux, the write operation principle, error causes, and troubleshooting methods are as follows: 1. introduction to the write function (1) contention between file I/O and standard I/O: according to the introduction in "advanced programming of UNIX environment, the differences between file I/O and preparation I/O mainly include the following: first, file I/O is implemented in the system kernel...
In linux, the write operation principle, error causes, and troubleshooting methods are as follows: 1. introduction to the write function (1) contention between file I/O and standard I/O: according to the introduction in "advanced programming of UNIX environment, the differences between file I/O and preparation I/O mainly include the following: first, file I/O is implemented in the system kernel, standard I/O functions provide a complete alternative to file I/O functions with Buffering. Therefore, file I/O is a relatively low-level I/O operation function, while standard I/O is a relatively high I/O. The standard I/O function abstracts open file models into "file streams ". Common file I/O include: open, write, create, close, read, etc. standard I/O include: fopen, freopen, fdopen, and getc. Second, standard I/O is generally the first choice for disk and terminal device I/O. when trying to use it for network I/O, that is, to operate the network socket, apply the file I/O. (2) blocking and non-blocking of file I/O (taking the write function as an example): As mentioned earlier in www.2cto.com, file I/O is an operation function with a buffer, in the actual operation process, blocking and non-blocking problems are inevitable. The following describes the blocking and non-blocking situations using the write operation:

The write function first places the data to be sent by the process in the process buffer, and then copies the data to the socket sending buffer. This may happen here, that is, when the data volume in the process buffer is greater than the data volume acceptable in the sending buffer, the application process will be suspended if it is in blocking mode, until all data in the process buffer is copied to the sending buffer, the kernel will not return the write function at this time. Therefore, if the write function returns normally in blocking mode, this does not mean that the data has been received by the other process. at most, it can only indicate that the data has been completely accepted by the sending buffer. if the data is in non-blocking mode, the write operation will fail, the kernel will immediately return the EAGAIN error. what needs to be declared here is that sometimes the EWOULDBLOCK error will be returned in some places. In fact, the two are essentially the same, but they are only used for different systems, the former mainly appears in the GNU system, while the latter mainly appears in the class BSD system. Www.2cto.com
[Extension 1] blocking and non-blocking conversion: switch the blocking mark of socket fd. Int fcntl (int fd, int cmd) int fcntl (int fd, int cmd, long arg). cmd indicates the command to be operated. common commands include F_GETFL: get the current status flag of fd F_SETFL: set the current status flag of fd [cpp] flags = (long) fcntl (pc-> fd, F_GETFL); bflags = flags &~ O_NONBLOCK;/* clear non-block flag, I. e. block */fcntl (pc-> fd, F_SETFL, bflags );
[Extension 2] view the sending cache size in Linux: sysctl-a | grep net. ipv4.tcp _ wmemnet. ipv4.tcp _ wmem = 4096 16384 81920 (these three values represent the minimum number of bytes in the sending buffer, the default number of bytes and the maximum number of bytes respectively) www.2cto.com 2. common write errors and cause analysis: we have already mentioned the cause of the EAGAIN error. The following describes the scenarios where the EPIPE error occurs. We know that TCP connection requires three handshakes, and exit requires four processes, while EPIPE is generated in the exit process of the socket process, which corresponds to the above schematic diagram, if the process on the B-side has been disabled (send FIN), but the-side still sends data to the other side due to various reasons (mainly not synchronized, at this time, the kernel on the side returns an EPIPE error, which sends a sigpipe signal to process A. by default, the process automatically exits. Recently, in the project process, because the keep-alive configuration time on the Apache server side is too short, FIN is issued too early, and the EPIPE error occurs on the client socket, finally, set the keep-alive time to a little longer. all problems are OK! Author: Chen lilong