3 ms·

A regular file has two obvious disadvantages: first, you write all the data to disk and read it back again, which costs you time and disk space. In a pipe, the

A regular file has two obvious disadvantages: first, you write all the data to disk and read it back again, which costs you time and disk space. In a pipe, the data is streamed, with the OS doing buffering for you. Second, if you have one process writing to a plain file and another process reading from it, you need some way of signaling when there's data ready to be read and when the reader should wait, or when the stream has ended. A pipe provides this for you: in blocking IO mode, the reader just issues a read() and blocks until the writer writes something.

antocv 13y ago
What if the file is in /tmp or shared memory then it wont cost that much time and no disk space/access? The blocking/signalling is still missing though.
- valleyer 13y ago
  Well, for one thing, on some systems (e.g., OS X), /tmp is disk-backed. But also, by writing out to /tmp on memory-backed systems, the lack of blocking means you grow memory use potentially indefinitely if the reader is slow or delayed for some reason. That will ultimately turn into swapping, which is just disk access again. There's also no great way to truncate the beginning of a regular file.
- hamburglar 13y ago
  I don't understand why you'd do it, but sure, if you're determined to avoid pipes even in situations where they'd be really well suited to the problem, a scheme using files on a RAM-based filesystem and roll-your-own signaling/blocking/buffering could conceivably be made approximately equivalent, performance-wise, to a pipe. Out of curiosity, is there some good reason you'd do this instead of just using a mechanism that's specifically made to solve this problem?
- jholman 13y ago
  The blocking/signalling is missing? What's wrong with $ ./producer > my_rambacked_file & $ tail -f my_rambacked_file > ./consumer Well, okay, I guess this way you don't get a signal that the producer is finished.

antocv 13y ago

What if the file is in /tmp or shared memory then it wont cost that much time and no disk space/access? The blocking/signalling is still missing though.

valleyer 13y ago
Well, for one thing, on some systems (e.g., OS X), /tmp is disk-backed. But also, by writing out to /tmp on memory-backed systems, the lack of blocking means you grow memory use potentially indefinitely if the reader is slow or delayed for some reason. That will ultimately turn into swapping, which is just disk access again. There's also no great way to truncate the beginning of a regular file.
hamburglar 13y ago
I don't understand why you'd do it, but sure, if you're determined to avoid pipes even in situations where they'd be really well suited to the problem, a scheme using files on a RAM-based filesystem and roll-your-own signaling/blocking/buffering could conceivably be made approximately equivalent, performance-wise, to a pipe. Out of curiosity, is there some good reason you'd do this instead of just using a mechanism that's specifically made to solve this problem?
jholman 13y ago
The blocking/signalling is missing? What's wrong with $ ./producer > my_rambacked_file & $ tail -f my_rambacked_file > ./consumer Well, okay, I guess this way you don't get a signal that the producer is finished.