Fork() and Pipe()

[Stuff_]

Can someone help me, or link me to a good website about the UNIX system call fork() and pipe() ?

 

I know WHAT they do, but really I'm mean to write a C program that forks 8 processes (I can do that easily, in for loop with a switch statement) and then creates 8 pipes as well, and passes messages from one process to the other.

 

I know how to create the pipes as well. I just am trying to understand the pipe() process, really. It seems confusing to me, but I think I just haven't been explained it well enough.

 

Any help would be great.

[Stuff_]

Bump.

Someone must be able to help, right? 

 

I see all these ridiculous posts about game development and what language to start, and they get tons of replies. But mine doesn't?

[ZeferiniX]

Bump.

Someone must be able to help, right? 

 

I see all these ridiculous posts about game development and what language to start, and they get tons of replies. But mine doesn't?

 

Might be best to put this in stackoverflow since there are more active and knowledgeable devs there compared here

[manon_gfx]

Hmmm, first time I find something on this forum that I really don't know. I would recommend looking in other places. And if you do figure it out, please post the solution here, would love to know!

[Stuff_]

I might try. I always see things posted there, and people are getting upset at a "duplicate question."

[Gob]

Really, the man pages are your best friend here: type "man pipe" in the command line. But these are also replicated everywhere, like http://man7.org/linux/man-pages/man2/pipe.2.html.

 

Just as an aside, I suspect the reason you are not getting many answers is because you are claiming to understand how to use pipes and what they do, and then don't really pose an answerable question. So it is hard for someone to give you an answer. I will try, though.

 

The "int pipe(int fds[2])" system call basically sets up a buffer in the kernel space that allows userland processes to intercommunicate. There is an example in the link I posted. But the gist is that you pass an array of two ints to the system call. If the system call is successful the array contains two File Descriptors. fds[0] is the read end of the pipe, and fds[1] is write end. After fork()ing the process, depending on the communication direction, the child and parent will use the close() system call on the end of pipe they are not using, and then use the write()/read() system calls on the corresponding end to send/receive the bytes to/from the kernel space buffer. There are other methods for inter-process communication, but they may require synchronization (for example shared memory, see "shmget").

 

Hope that helps.

[Mojo-Jojo]

Can someone help me, or link me to a good website about the UNIX system call fork() and pipe() ?

 

I know WHAT they do, but really I'm mean to write a C program that forks 8 processes (I can do that easily, in for loop with a switch statement) and then creates 8 pipes as well, and passes messages from one process to the other.

 

I know how to create the pipes as well. I just am trying to understand the pipe() process, really. It seems confusing to me, but I think I just haven't been explained it well enough.

 

Any help would be great.

Hey there. Hope I'm not late, been too busy to really answer this one. Did see it before.

 

There's two types of pipes: named and unnamed. You can use named pipe is processes that you manually start, for example two completely separate parent tasks.

The named pipes are also called FIFO buffers; they're two-way buffers that can be read from and written to by one task.

Unnamed pipes require less program code because they're not created on the filesystem like FIFO Named pipes are. They're unidirectional though, so you'll have to have an incoming and an outgoing pipe for each child task. Only 1 parent and its children have access to the same unnamed pipe.

 

You said you know how to use them, but aren't sure how pipe() itself works.

Pipe internally asks the kernel to look for the first free file descriptor and give it to the task requesting it. It hands them out in ascending order. File Descriptors are task-bound, which is why you can't use unnamed pipes in other processes; their descriptor with the same ID points to nothing. Every task can get up to 256 File Descriptors.

 

File descriptors are used in Linux to do a lot of things; access files, named pipes, even writing to terminal outputs happens with a file descriptor. Think about STDOUT for example. This is why it's also possible to duplicate a pipe into the stdin or stdout of another program.

 

As for fork:

Fork creates a second process with a shared text segment (where the code resides) and user data segment (variables and such). So basically the program is exactly the same, with the return value of forn() deciding where to go next. The new child gets its own process ID and the kernel then points its execution pointer to where it was forked. As soon as either changes a variable, they get their own data segments. If you need to share memory, I think looking up Shared Memory is useful. 

It makes sure that the file descriptors of the parent are available to the child. Which is why unnamed pipes work.

 

I've attached a zip with source code for a recent college assignment I did; https://dl.dropboxusercontent.com/u/2232135/ops8.zip

I hope this helps somewhat!

[Stuff_]

I appreciate the reply. I think I'm starting to grasp it better. 

 

This diagram is how you would set up a pipe from a parent to child IPC?

 

http://imgur.com/ROpT5XS

[Mojo-Jojo]

I appreciate the reply. I think I'm starting to grasp it better. 

 

This diagram is how you would set up a pipe from a parent to child IPC?

 

http://imgur.com/ROpT5XS

Yeah that seems right to me. In essence all pipe communications happen through the kernel; so the calls used for it basically "ask" the kernel to help it with the tasks.