Adverse consequences of mixing the Select function with Stdio (RPM)

Originating From: http://www.cppblog.com/mysileng/archive/2013/01/15/197284.html

Today, I was watching UNP6.5 festival, and learned the consequences of mixed select and stdio. The process is hereby tested. Before you experiment, you need to make a few clear points:
The I/O functions of the 1.stdio stream are different from the system I/O functions. The stdio stream function is buffered in both the user space and the kernel, and the system I/O functions are buffered only in the kernel, with no user space.

2.stdio stream I/O function buffering mechanism: In the face of the file is full buffer, the face of the device with the line buffer. (The test uses a keyboard and screen), so the stdio function used in the experiment uses row-and-row buffering.

The 3.select function is prepared for a descriptor to be readable and writable, whether the data in the kernel buffer reaches a certain minimum standard, rather than the user buffer. This means that the Select function does not know the existence of the user buffer.

First, I wrote a simple select function program for the system I/O function:

The program gives the SELECT function a descriptor for only the keyboard that is set. This means that if the keyboard descriptor is ready, it will no longer block. But here's a problem, after unblocking, we only read 3 bytes from the kernel buffer at most, this time there are two things:
(1) The data stored in the kernel space is less than or equal to 3 bytes and is read all the way. The next time the Select function is called again, it should definitely block because the kernel buffer entered by the keyboard already has no data.
The situation is as follows (kernel space is only 3 bytes: 1 2 \ n):


(2) If the data in the kernel space is more than 3 bytes, but because a maximum of 3 bytes can be read, it will inevitably cause the data in the kernel to be read. Will it block the next time you encounter the Select function?
See below:

When we enter 5 characters (1 2 3 4 \ n), the first read out 3 characters, the kernel space is left with 2 characters, and then hit the Select function again, by default if the number of keyboard kernel space characters greater than 1,select will not block the keyboard descriptor. The results are also verified, and read 2 bytes, and there is no blockage.
In summary, select is a buffer that can see the kernel space. Can you see the user space buffer? We switched to the I/O function of the stdio stream to continue the experiment.

--------------------------------------------------------------------
The stdio stream I/O functions use the Select function as follows:


The program reads the data from the keyboard using the GETC function of the stdio stream, and the results are as follows:

We entered 5 characters (1 2 3 4 \ n), and the result was only 1 characters, then blocked. We analyze, first enter 5 characters, these 5 characters are put into the user buffer, because the last one is a newline character and stdio face device using the row buffer mechanism, so these 5 characters are immediately followed from the user buffer into the kernel buffer. Then the SELECT function is called, and the Select function discovers that there is data in the kernel space and does not block the return. The GETC function then takes one character from the user-space output buffer because the user-space output buffer does not have data, then the data in the kernel space is transferred to the user-space output buffer, and then GETC returns. Then ran into the Select function, because the kernel buffer space data has been put into the user space output buffer, so the kernel buffer no data, then select think the keyboard is not ready, so blocking. Although blocked, but need to notice when this time, the user space is 4 character data, is ignored by the Select function.

Next, suppose we enter 2 characters (1 \ n), what will happen?

Output a pair of things that's going on and we continue to analyze. When entering 2 characters (1 \ n), the kernel space buffer has no data and the user space output buffer has 4 characters. 2 characters are brushed into the kernel space buffer according to the same principle as the previous paragraph. The Select function is called and is found to have 2 characters, so it does not block the return. The GETC function extracts a character from the user output buffer, prints the stardard ...--2 and then returns. Loop again, calling the Select function. The key is here, it's not the same as the last time. This time the kernel space buffer also has the last 2 characters left, so still do not block return, call the GETC function to continue printing ... The key here is the GETC function. The GETC function does not move the data in the buffer of the kernel space into the output buffer of the user space when there is data in the user output buffer, so that the kernel space buffer keeps the data. This will persist until the data buffered by the user-space output is exhausted. So the above-mentioned strange printing results can be explained.
In summary, the SELECT function is really invisible to the user space buffer.


So if you use the Select function, use the stdio stream function with caution.

Adverse consequences of mixing the Select function with Stdio (RPM)