0

read method of files objects read until EOF. We know that EOF is not a value, but it's a condition which takes place when there's no more data to read from streams.

Wikipedia: EOF

In computing, end-of-file (commonly abbreviated EOF[1]) is a condition in a computer operating system where no more data can be read from a data source. The data source is usually called a file or stream.

This is all great. Contuning reading the same page:

Block-reading functions return the number of bytes read, and if this is fewer than asked for, then the end of file was reached or an error occurred (checking of errno or dedicated function, such as ferror is often required to determine which).

I could imagine that read will request N number of bytes each time it read if N < reguest number of bytes then EOF. But If I had a command like this: 

$ python writer.py | python reader.py

#writer.py
print("Hi", flush=True)
print("Billie Jean!")
import time
time.sleep(10)
print("Bye Billie :)")

#reader.py
import sys
print(sys.stdin.read())
print("after")
#print(input())

there are two scripts communicating via a pipeline. Basically, the first script's output stream is a pipe connected to the input stream of the second script, reader.py. However, there's something interesting, read now should get puzzled! Since read reads N number of bytes just like was mentioned above, well at least in my assumption read reads N number of bytes I could be worng!

Then if read retrieves N number of bytes, the first print in the script writer.py sends just the string "Hi" to the pipe but the second print doesn't get transmitted to the pipe and sits in buffer because I didn't flush the buffer, therefore next time read requests N number of bytes from the pipe it should think EOF condition is satisfied? I know one thing, read blocks until the first process finishes, unlike readline for example which doesn't block. It seems read is smarter than I thought, but how does it do its magic? How does it know that there's still a chunk of data to be read if it reads N number of bytes from pipe?

Billie Jean sits in buffer for 10s each time I run my scripts?! :P

GIZ
  • 4,409
  • 1
  • 24
  • 43
  • 4
    EOF is only satisfied if the output side of the FIFO is closed. Not just "if there's nothing in the FIFO", but if there's nothing in the FIFO *and the output side of the fifo is **closed**"*. – Charles Duffy Jun 12 '17 at 18:47
  • Related (maybe related enough to be a duplicate?) - https://stackoverflow.com/questions/40352825/prevent-reading-data-from-an-empty-fifo-from-blocking – Charles Duffy Jun 12 '17 at 18:48
  • 2
    If you can read C, you may find [How feof() works in C](https://stackoverflow.com/questions/12337614/how-feof-works-in-c) helpful. Briefly, `fgetc` (and its stdin version `getchar`) is a blocking read that reads a single byte and returns the byte value as an integer n, 0<=n<255. If the stream was closed, it returns the special value EOF, which is conventionally -1. – PM 2Ring Jun 12 '17 at 18:54
  • @PM2Ring, Ok, then when you try to read a closed file, C's `fgetc` and `getchar` return -1. But the reading takes place before the file gets closed? That is, these functions will read the stream byte by byte until pipe gets closed so they no longer can read? So long as the stream or the pipe in our case isn't closed, they keep reading. – GIZ Jun 12 '17 at 20:36
  • 1
    Pretty much. The only way a stream reading process knows that there's no more data is if it gets an EOF, or if it queries the stream object with `feof()` (or equivalent). Here's another helpful answer: https://stackoverflow.com/a/22210600/4014959 – PM 2Ring Jun 12 '17 at 20:52
  • @PM2Ring Alright, thank you. – GIZ Jun 12 '17 at 21:17

0 Answers0