Forking

So in my program I have a server / parent process that has a number of client / child processes that need to be running concurrently. They need to share a stream of data (going from the parent to the children, I'm pretty sure I don't need any data going the other way). They also share a linked list of structs (where each node represents a child, and contains the file pointer for the FIFO to the client, the pid, a unique name, etc....). The first node is malloc'd before the first process fork's, and it's expanded as new children are created by other children processes.

So far, so good - does anyone see any problems with this design? Any thoughts or comments? It's my first larger project in Linux, so I'm running into a lot of new stuff.

My main question, however, is about fork'ing and exec'ing. Right now the code is tiny - under 100 lines, and I doubt it'll make it past 150 by the time I'm done. So when I fork, I just have the parent call server(), and the child call client(). Is that bad? Should I put those methods in separate processes and call them through exec()? Are there drawbacks one way or the other? Google only seems to yield man page entries and very simplistic tutorials that don't answer the question!

edit: If compiling them in separate files and exec'ing them results in a much smaller "footprint" - I'd definitely like to do it. But if it doesn't make a big different, I'd just rather contain everything to one small file - it's more my style... The code for the client process might grow a little bit, but the server code is going to stay under 20 lines I think...

>> ... does anyone see any problems with this design?
Sounds good to me. If these nodes are accessed regularly from within each thread of execution, just keep locality in mind for better cache performance.

>> I just have the parent call server(), and the child call client(). Is that bad?
No. It's ideal.

>> call them through exec()?
Not unless you have a compelling reason to do so. It's more efficient for the OS to create a new process instance for an image it's already loaded - which includes resolving dynamic libs and other startup fun.

gg

Quote:

---

Originally Posted by sean

... the FIFO to the client ...

---

I understand FIFO to mean first-in-first-out. In this context, does it mean anything other than an ordinary queue?

Quote:

---

Originally Posted by sean

Google only seems to yield man page entries and very simplistic tutorials that don't answer the question!

---

I've only recently begun playing around with fork(), and run into the same problem. I have some idea of when it would be useful, and it seems to make sense to me that a server would make good use of multiple child SERVER processes to service multiple clients, but I don't see why you would have a server parent and multiple child clients in the same module. Please help me understand that.

Also, can either of you point out something better than those simplistic tutorials that talks about appropriate uses for fork()?

Quote:

---

I understand FIFO to mean first-in-first-out. In this context, does it mean anything other than an ordinary queue?

---

It's a special file. One process can open it to write stuff, and the other can open to read stuff, and it's just a pipe to send data down. First-in-first-out. Kind of a queue...

Quote:

---

it seems to make sense to me that a server would make good use of multiple child SERVER processes to service multiple clients

---

No - this isn't a server in the web sense of the word. In my program I unavoidably have a number of process running more or less the same program, and the "server" just manages those processes. It recieves data from stdin, uses it to either send instructions to the clients, close them, manipulate them, etc... If I had multiple servers, things would get very out of hand, without giving me an advantage...

Quote:

---

Also, can either of you point out something better than those simplistic tutorials that talks about appropriate uses for fork()?

---

I'm afraid not - if Google isn't yielding you what you're looking for, I would recommend writing a small program that implements it, and then just try different things to see what happens - I've been doing that a lot lately. The only downside is if you start doing something that's very bad practice, you ought to have someone with more experience check your code out - hence this thread.

I think of forking as just a means for multi-threaded programming. In this case, each "thread" is isolated within a process. One example of this concept in practice is the Google Chrome browser: http://dev.chromium.org/developers/d...process-models

How Apache can be configured may be interesting as well: http://httpd.apache.org/docs/2.0/mod/worker.html

gg

Quote:

---

Originally Posted by sean

It's a special file. One process can open it to write stuff, and the other can open to read stuff, and it's just a pipe to send data down. First-in-first-out. Kind of a queue...

---

Aha ... I guess, sean, you're referring to the thing produced by mkfifo()?

Codeplug: thanks for those examples.

I'm thinking that in a single-processor environment, fork() is useful only when there will be multiple threads (in the abstract sense) of execution, you want each thread to start with a complete copy of the program's state which it can modify, but you don't want those modifications to affect the state of the main program or that of other threads. Does that sound reasonable? Am I overlooking other uses?