Bdtyktl

I am studying Operating Systems on my own from the MOOC lectures available online and wanted to work on xv6. I was reading the Documentation on xv6 and in chapter 0 when it is talked about pipes (pg. 13), I have a doubt.

int p[2];

char *argv[2];

argv[0] = "wc";

argv[1] = 0;



pipe(p);

if(fork()==0){

close(0);

dup(p[0]);

close(p[0]);

close(p[1]);

exec("/bin/wc", argv);

}

else{

write(p[1], "hello worldn", 12);

close(p[0]);

close(p[1]);}

It is written that:-

Now, the child dups read end onto file descriptor 0, closes fds in p, and execs wc. When wc reads from its standard input, it reads from the pipe. The parent writes to the write end of the pipe and then closes both of its file descriptors.

Also, it is mentioned that the processes do not share variables, i.e., changes made in one process do not reflect in that of the other.

Now, here, I write in parent process and if child reaches exec before parent finishes writing to p[1], the child will wait and after it has finished writing, child will read from p[0] and will do the exec. So, is it correct to say that there are special privileges for pipes which makes them support interprocess communication by sharing pipes? So, unlike variables whose changes would not reflect in other process, pipes are shared and hence, their changes reflect in one another?

Is the above reasoning correct?

Your reasoning is mostly right. It's not that pipes have special privileges, though; you're just thinking of them as the wrong kind of thing. A pipe isn't a variable, it's an OS object created in the kernel using the pipe system call, and can be open in one or more processes at a time. Data written into the writable end of a pipe (that is, the second of the two file descriptors created in the pipe(p) call and stored in the array p) is readable at the other file descriptor (p[0] here, which then gets duplicated to file descriptor 0, which is the file descriptor used for stdin). This reading from and writing to the pipe is possible regardless of which processes have those file descriptors open.

You may notice that you don't just assign values to pipes; you write to them like files (and write is a system call; the program is telling the kernel to do something, not just changing a value in its local memory). In fact, if you think of pipes as being like files, except they can be anonymous (unnamed), can't have file descriptors capable of both reading and writing (that is, they are unidirectional), and only hold data between writing and reading and not after the data is read or all file descriptors to the pipe are closed, you won't be far wrong. Just like two processes can share access to the same file, so can two processes share access to a pipe (the way shown here is a common way to create a pipe for two processes to share, but you can also have two completely unrelated processes open a "named pipe" which is the same idea except you give it a name like a file, and each process opens one end at a time and specifies whether it wants the read or write end).

Manually creating pipes is usually done for interprocess communication, but not necessarily in source code. Also, both programs don't need to be running at the same time. If you write a line in a shell using | (the "pipe character"), you are telling the shell to create a pipe from the stdout of the first command into the stdin of the second command (much like your example above creates a pipe into the stdin of /bin/wc). That is, a shell command like ls | wc) creates a pipe with the writable end set as file descriptor 1 (stdout), executes ls and thus captures its output in that pipe, then sets the readable end as file descriptor 0 (stdin) and executes wc, which duly reads the output of the now-finished ls and outputs the result to its own stdout, which ends up on your terminal.