Linux socket read Blocking

 

The read function is only a common interface for reading file devices. Whether blocking is performed depends on the properties and settings of the device. In general, the default read method for reading character terminals, socket descriptors on the network, and MPs queue files is blocking. If you are reading files on a disk, it is generally not blocked. However, the use of the lock and fcntl settings to cancel the file O_NOBLOCK status will also produce a blocking read effect.

How to read data from the pipeline in a non-blocking manner? Because when I use the read function, if the pipeline has no data, it will block ???

My code is:
Char chBuff [32];
Read (file_pipe [0], chBuff, 16 );

If there is no data in the pipeline, this function will never be returned. Is there any other way to do this? If there is data in the pipeline, it will be read and no data will be returned immediately ??

Alternatively, you can pass in the O_NONBLOCK parameter during open, and enable/fcntl (fd, F_SETFL, O_NONBLOCK) in non-blocking mode)

Set O_NONBLOCK flag in mode

Each TCP interface has a sending buffer. You can use the SO_SNDBUF interface option to change the buffer size. When an application process calls write, the kernel copies all data from the buffer of the application process to the sending buffer of the Set interface. If the sending buffer of the Set interface cannot accommodate all data of the application (or the buffer of the application process is greater than the sending buffer of the Set interface, or the sending buffer of the Set interface has other data ), the application process will be suspended (sleep ). It is assumed that the Set interface is blocked, which is the default setting. The kernel will not return data from the write system call until all data in the application process buffer is copied to the sending buffer of the Set interface. Therefore, a successful response from the write call to write a TCP set of interfaces only indicates that the buffer of the application process can be reused. It does not tell us the peer
The TCP or application process has received data.
The TCP fetch interface sends the buffer data and sends it to the peer TCP. The process is based on all the rules of TCP data transmission. The peer TCP must confirm the received data. Only when the peer Ack is received can the local TCP Delete the confirmed data in the interface sending buffer. TCP must keep data copies until peer confirmation.

1 input operation: read, readv, Recv, recvfrom, recvmsg

If a process calls one of these input functions for a blocked TCP interface, and there is no data readable in the receiving buffer of the interface, the process will be put into sleep until it reaches some data. Since TCP is a byte stream protocol, the wake-up process only needs to reach some data: the data may be either a single byte or a complete data in a TCP shard. To read a fixed number of data, you can call the readn function or specify the msg_waitall flag.

Since UDP is a datagram protocol, if the receiving buffer of a blocked UDP interface is empty, the process that calls the Input Function on it will be put into sleep until it reaches a UDP datagram.

For non-blocking sets of interfaces, if the input operation cannot be met (for TCP sets of interfaces, there is at least one byte of data readable, and for UDP sets of interfaces, there is a complete datagram readable ), the corresponding call will immediately return an ewouldblock error.

2 output operations: Write, writev, send, sendto, sendmsg

For a TCP interface, the kernel copies data from the application process buffer to the sending buffer of the interface. For blocked sets of interfaces, if there is no space in the sending buffer, the process will be put into sleep until there is space.

For a non-blocking TCP interface, if there is no space in the sending buffer, the output function call will immediately return an ewouldblock error. If the sending buffer has some space, the returned value is the number of bytes that the kernel can copy to the buffer. This number of bytes is also called the insufficient count (short count)

The UDP interface cannot be in the real sending buffer zone. The kernel only copies the application process data and transmits it down the protocol stack. It is gradually assigned the UDP header and IP header. Therefore, for a blocked UDP interface, the output function call will not be blocked for the same reason as the TCP interface, but may be blocked for other reasons.