不关闭C冲洗管道

Question

I have found a lot of threads in here asking about how it is possible to flush a pipe after writing to it without closing it. In every thread I could see different suggestions but i could not find a definite solution.

Here is a quick summary:

1. The easiest way to avoid read blocking on the pipe would be to write the exact number of bytes that is reading.

2. It could be also done by using ptmx instead of a pipe but people said it could be to much.

Note: It's not possible to use fsync with pipes

Are there any other more efficient solutions?

Edit:

The flush would be convenient when the sender wants to write n characters but the client reads m characters (where m>n). The client will block waiting for another mn characters. If the sender wants to communicate again with the client leaves him without the option of closing the pipe and just sending the exact number of bytes could be a good source of bugs.

The receiver operates like this and it cannot be modified:

while((n=read(0, buf, 100)>0){
     process(buf)

so the sender wants to get processed: "file1" and "file2" for which will have to:

write(pipe[1], "file1\0*95", 100);
write(pipe[1], "file2\0*95", 100);

what I am looking is for a way to do something like that (without being necessary to use the \\n as the delimeter):

write(pipe[1], "file1\nfile2", 11); //it would have worked if it was ptmx

(Using read and write)

Answer 1

Flushing in the sense of fflush() is irrelevant to pipes, because they are not represented as C streams. There is therefore no userland buffer to flush. Similarly, fsync() is also irrelevant to pipes, because there is no back-end storage for the data. Data successfully written to a pipe exist in the kernel and only in the kernel until they are successfully read, so there is no work for fsync() to do. Overall, flushing / syncing is applicable only where there is intermediate storage involved, which is not the case with pipes.

With the clarification, your question seems to be about establishing message boundaries for communication via a pipe. You are correct that closing the write end of the pipe will signal a boundary -- not just of one message, but of the whole stream of communication -- but of course that's final. You are also correct that there are no inherent message boundaries. Nevertheless, you seem to be working from at least somewhat of a misconception here:

The easiest way to avoid read blocking on the pipe would be to write the exact number of bytes that is reading.

[...]

The flush would be convenient when the sender wants to write n characters but the client reads m characters (where m>n). The client will block waiting for another mn characters.

Whether the reader will block is entirely dependent on how the reader is implemented. In particular, the read(2) system call in no way guarantees to transfer the requested number of bytes before returning. It can and will perform a short read under some circumstances. Although the details are unspecified, you can ordinarily rely on a short read when at least one character can be transferred without blocking, but not the whole number requested. Similar applies to write(2) . Thus, the easiest way to avoid read() blocking is to ensure that you write at least one byte to the pipe for that read() call to transfer.

In fact, people usually come at this issue from the opposite direction: needing to be certain to receive a specific number of bytes, and therefore having to deal with the potential for short reads as a complication (to be dealt with by performing the read() in a loop). You'll need to consider that, too, but you have the benefit that your client is unlikely to block under the circumstances you describe; it just isn't the problem you think it is.

There is an inherent message-boundary problem in any kind of stream communication, however, and you'll need to deal with it. There are several approaches; among the most commonly used are

• Fixed-length messages. The receiver can then read until it successfully transfers the required number of bytes; any blocking involved is appropriate and needful. With this approach, the scenario you postulate simply does not arise, but the writer might need to pad its messages.

• Delimited messages. The receiver then reads until it finds that it has received a message delimiter (a newline or a null byte, for example). In this case, the receiver will need to be prepared for the possibility of message boundaries not being aligned with the byte sequences transferred by read() calls. Marking the end of a message by closing the channel can be considered a special case of this alternative.

• Embedded message-length metadata. This can take many forms, but one of the simplest is to structure messages as a fixed-length integer message length field, followed by that number of bytes of message data. The reader then knows at every point how many bytes it needs to read, so it will not block needlessly.

These can be used individually or in combination to implement an application-layer protocol for communicating between your processes. Naturally, the parties to the communication must agree on the protocol details for communication to be successful.