C Input output wait queue between processes - using pipes (inter process communication)

E

escape

In a multiple process application where input and output is written and read using pipes, the data reads and writes are synchronized by a command pipe as a "wait queue". A single byte is sent in a (command) pipe and reading it notifies to start reading the next data.

What is the best practice and recommendation to synchronize the data reads and writes?

Should I be using UNIX domain sockets instead of pipes? Is it possible that some byte writes or reads are discarded?

Linux TCP connections have been like that: It was possible to read the length of the message and a complete message after the length. If the data was read three times, the data was not anymore available in a third read. Why?

With best

escape
 
escape said:
A single byte is sent in a (command) pipe and reading it notifies to start reading the next data.
Click to expand...
I don't understand your comment, but that doesn't mean it's wrong. All data is always sent one byte at a time.

What is the best practice and recommendation to synchronize the data reads and writes?
Click to expand...
Depends on the use case. My favorite is arranging things such that no synchronization is even needed: every process has exactly one input and exactly one output, and can read whenever it finds data, and writes it output whenever it's ready. Sadly, the world is sometimes more complex than this.

Should I be using UNIX domain sockets instead of pipes? Is it possible that some byte writes or reads are discarded?
Click to expand...
As long as you are on a single machine, it makes little difference. But I would do the following: In reality, you don't want to send bytes, you probably want to send interestingly complex messages. So you end up having to spend effort encoding and decoding those messages into a stream of bytes. Why don't you use a library that encapsulates that and allows you to send whole RPCs (remote procedure calls), where the job of packing and unpacking the messages is done for you?

Regarding "changes": At the level of programming API at this level, there are few changes.
 
Thanks for the answer. There was actually a synchronization problem in the program and the words character per character helped really much to solve the problem later. The problem was to:
  1. Write the output in a buffer.
  2. Send a command to know that the next chunk of data is coming.
  3. Change the buffer into an output buffer to write in a pipe and flush.
What happened was that I started to read about the kernel wait queues. There is a possibility of a deadlock if the wait queues using the system resources do not get higher priority. The application here is a web application and the problem does not apply. Something else. It looks like the wait queues are an advanced subject most people do not know. An excellent video in an URL: <url> .

best, escape
 
You must log in or register to reply here.
Back
Top