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.