An Operating Systems Vade Mecum

300 Co-operating Processes Chapter 9seen them. A broadcast pipe would give C the first 5 bytes on the pipe, then give B thefirst 4 bytes, leaving 5 bytes unread by C and 6 bytes unread by B. This situation isshown in Figure 9.3.As you can see, broadcast pipes require much more state information to be savedby the pipe manager (as we will call this component of the kernel) for each pipe — allthe data that have not yet been read by even one of the processes having this pipe openfor reading, and a pointer for each process indicating which byte it will read next. Incontrast, a non-broadcast pipe has less state information — just the data that have notbeen read.Second, we can define pipes with the delimiting property, which says that the piperemembers boundaries between one write and the next. We provide two kinds of read:ReadBytes(pipe number, how many). This call returns the given number ofbytes from the pipe, blocking the caller if that many bytes are not yet available.ReadRecord(pipe number). This call returns bytes up to the next boundarybetween two writes.In Figure 9.4 we show B writing just as before. Now C first executes ReadRecord, getting6 bytes. If C then executes ReadByte for 2 bytes, it takes part of the next record.Finally, C can get the rest of the current record by calling ReadRecord.B writesB writesunwritten0 1 2 3 4 5 6 7 8 9 10C readsB readsunread by Cunread by BFigure 9.3 Reads and writes on a broadcast pipeB writesB writesunwritten0 1 2 3 4 5 6 7 8 9 10C readsC reads record C reads record unreadFigure 9.4 Reads and writes on a delimited pipe