[comp.lang.c] Fork and Join, Pipe in C

GR2173%SIUCVMB.BITNET@wiscvm.wisc.EDU (06/08/87)

Hi,
  I am currently working on my research using C concurrent programming
technique of fork & join and pipe. I am new to the C language and
I have a couple of questions to ask.
   Are there any other ways of creating more than one child at a time.
   The method I am using is read in the number of processes and use
   this variable to determine the number of children to fork using
   a simple FOR loop in C.
Are there any books on these topics. I am using the VAX 4.2 BSD.
Any lead will be greatly apprepriated. Thanks in advance.

where: gr2173@siucvmb.bitnet
name : aloysius lau

edw@ius2.cs.cmu.edu (Eddie Wyatt) (06/08/87)

   If the child processes that you are forking don't use
much of the code that the parent usings, I sugguest you use
vfork and execl to spawn processes.  vfork is much faster than
fork since it doesn't copy the parents address space  but it has
the bad side effected of using the parent's address (like shared
memory).  That is why its recomment that the child process do
an execl immediately after a vfork to load a new image into core.

  You might want to take a look at MACH operating system written here
at CMU.  It suppositely implements threads in a much more eligent
manner.  MACH is also upwardly compatible with Unix 4.2 and may
end up becoming Unix 5.0.

-- 
					Eddie Wyatt

e-mail: edw@ius2.cs.cmu.edu

guy@gorodish.UUCP (06/08/87)

>   I am currently working on my research using C concurrent programming
> technique of fork & join and pipe.

This isn't a C technique, it's a UNIX technique.  I'm redirecting
further discussion to comp.unix.questions/INFO-UNIX.

>    Are there any other ways of creating more than one child at a time.
>    The method I am using is read in the number of processes and use
>    this variable to determine the number of children to fork using
>    a simple FOR loop in C.

No, there is no way in UNIX to create processes other than "fork",
and that only creates one at a time.

> Are there any books on these topics.

There are lots of books on programming under UNIX, some of which will
discuss this.  There's a book by Brian Kernighan and Rob Pike, titled
"The UNIX Programming Environment", which has been highly recommended
by many people.  (I don't know if it discusses this or not.)  There
is also a document called "UNIX Programming", by Kernighan and
Ritchie, that comes with various versions of UNIX.
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com

mar@hpclla.UUCP (06/09/87)

An excellent book that covers programming in C under the Unix
environment is: Advanced UNIX Programming by Marc J. Rochkind (Prentic-Hall)
It does assume a knowledge of C syntax, and general knowledge of the UNIX
operating system.

henry@utzoo.UUCP (Henry Spencer) (06/21/87)

>    If the child processes that you are forking don't use
> much of the code that the parent usings, I sugguest you use
> vfork and execl to spawn processes.  vfork is much faster than
> fork since it doesn't copy the parents address space...

If vfork is much faster (as opposed to slightly faster) than fork, it is
time to complain to the supplier of your Unix, asking why he hasn't
implemented fork efficiently.  Even Berkeley *intended* to fix this, as
witness the comments on the vfork manual page.  Sensible vendors have
long since implemented copy-on-write fork, which eliminates most of the
copying involved in fork, thus eliminating most of the reason to use the
ugly and brain-damaged vfork.
-- 
"There is only one spacefaring        Henry Spencer @ U of Toronto Zoology
nation on Earth today, comrade."   {allegra,ihnp4,decvax,pyramid}!utzoo!henry

guy%gorodish@Sun.COM (Guy Harris) (06/22/87)

(Again, we redirect this to comp.unix.questions/INFO-UNIX.)

> If vfork is much faster (as opposed to slightly faster) than fork, it is
> time to complain to the supplier of your Unix, asking why he hasn't
> implemented fork efficiently.  Even Berkeley *intended* to fix this, as
> witness the comments on the vfork manual page.  Sensible vendors have
> long since implemented copy-on-write fork, which eliminates most of the
> copying involved in fork, thus eliminating most of the reason to use the
> ugly and brain-damaged vfork.

Or, at least, sensible vendors that are implementing on hardware that
provides the ability to specify, with a relatively small granularity,
regions of a process' address space such that attempts to modify them
will cause traps.  If, for example, you are stuck with
write-protecting the entire data or stack segment, copy-on-write may
not buy you much.  Fortunately, most machines don't impose obnoxious
restrictions of that flavor.

The only remaining reason to use vfork is that one has written ugly
and brain-damaged code that depends on the semantics of "vfork".
Such code does, unfortunately, exist; one of the pre-releases of
4.3BSD used this crock in "find", but it was fixed before 4.3BSD went
out the door in its final form.  If anybody has written code of this
sort, they should hang their head in shame and then go out and fix it
NOW.
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com

mouse@mcgill-vision.UUCP (der Mouse) (06/23/87)

In article <1186@ius2.cs.cmu.edu>, edw@ius2.cs.cmu.edu (Eddie Wyatt) writes:
> If the child processes that you are forking don't use much of the
> code that the parent usings, I sugguest you use vfork and execl to
> spawn processes.  [vfork is faster but borrows the parent's address
> space in an unclean way.]

Unfortunately, doing vfork/exec also requires that you split your
program up into multiple (binary) files and somehow teach one of them
(the parent) how to compute a path pointing to the part to be executed
by the child.

					der Mouse

				(mouse@mcgill-vision.uucp)

ado@elsie.UUCP (Arthur David Olson) (06/23/87)

In article <8174@utzoo.UUCP>, henry@utzoo.UUCP (Henry Spencer) writes:
> If vfork is much faster (as opposed to slightly faster) than fork, it is
> time to complain to the supplier of your Unix. . .Even Berkeley *intended*
> to fix this, as witness the comments on the vfork manual page.  Sensible
> vendors have long since implemented copy-on-write fork. . .

Let's go easy on the folks at Berkeley.  Many programmers fail to deliver on
their announced intentions--even when the intentions have been announced before
large audiences at Usenix conferences (the 1987 Washington D.C. conference
leaps to mind), not just in manual page comments.
--
UNIX is a registered trademark of AT&T.
-- 
	UUCP: ..seismo!elsie!ado	   ARPA: elsie!ado@seismo.CSS.GOV
	     Elsie and Ado are trademarks of Borden, Inc. and Ampex.