vfork()

[oddabd83]

Hi!
I do not understand what's the use of vfork() when it blocks the parent while the child is forked. We use fork when we want to do 2 things:

1) Lighten the load of the parent process by creating many CONCURRENT child processes.
2) Let the necessary blocking read/write to CONCURRENTLY run in the parent, while the rest of the program resides in the child. E.g. multithreaded webservers.

Hence i feel that the vfork() is useless as it doesn't allow any concurrent-ness at all.

Please correct me if I am wrong.

[wje_lf]

vfork() does not seem useful in your situation.

The only advantage of vfork() is performance. It should be used only when the child process plans to call some function in the exec() family right away. Instead of creating a new address space for the child process, the child process runs in the parent's address space, thus speeding things up. And, as you hinted, the parent process will not continue until the child process either exec()s or exit()s.

Hope this helps.

[oddabd83]

Hey thanks for replying. I guess your answer will at least set me on the right track. Right now I'm building a webserver on a uCSimm board that runs uClinux. Unfortunately, uClinux do not support fork() commands, thus making it very difficult to make a multi-threaded web server.

Any suggestions??

[wje_lf]

Does it support vfork()?

If it does, and you do a vfork(), do all open file descriptors remain open?

[oddabd83]

it does support vfork(), and the file descriptors will remain open. However, since I would like to build a multithreaded server, would it not be the same if I simply code it without vforking the processes?

About my progress right now, I'm trying to use select() to "wait" on all reads from the socket listener and file descriptors. What do you think?

[wje_lf]

I assume that by "multithreaded" you don't mean POSIX threads. POSIX threads should be used as a last resort, when a large percentage of elapsed clock time time would be spent communicating between threads. Debugging programs which use POSIX threads can be a pain because of the shared heap address space.

Assuming for the moment that you're not using POSIX threads, the next question arises: do you want to be able to serve more than one request at a time? You can do so without vfork() if you're doing asynchronous I/O and can keep everything straight. You'll avoid the hit of doing an exec() every time a request comes in. That's the only advantage I can think of for avoiding vfork().

The cost, though, is the same as for POSIX threads: all requests share the same heap space, making debugging difficult.

I recommend that you code this puppy so that it does everything either with vfork() or without, depending on a compile-time variable, thus:

.
.
.
(code code code)
.
.
.
#if USE_VFORK
(stuff you compile only when using vfork())
#else
(stuff you compile only when not using vfork())
#endif

... and compile it with one of these command lines:

gcc -DUSE_VFORK=0 [your normal gcc command line stuff here]
gcc -DUSE_VFORK=1 [your normal gcc command line stuff here]

Don't use vfork() until you find a bug that involves corrupted heap space. Then use vfork() until you've fixed the bug, so every thread only messes up its own space.

And yes, select() is the way to go with I/O, with or without vfork(). Two recommendations:

1. Make all your I/O (including on the listening socket) be non-blocking.
2. Run, don't walk, to your nearest bookseller and get Volume 1 of Addison-Wesley's UNIX Network Programming, by W. Richard Stevens of happy memory. You'll save time in the long run if you're familiar with the content of that book.