gillies@p.cs.uiuc.edu (05/17/89)
Somewhere I read a quote: "OS/2 uses a lot of memory because it implements sophisticated features, such as lightweight processes" *snicker*. God knows what a lightweight process is, if needs gobs of memory just to be "lightweight"?!!??
cgeisler@water.waterloo.edu (Craig Eisler) (05/20/89)
In article <75800069@p.cs.uiuc.edu> gillies@p.cs.uiuc.edu writes: >Somewhere I read a quote: >"OS/2 uses a lot of memory because it implements sophisticated >features, such as lightweight processes" > >*snicker*. God knows what a lightweight process is, if needs gobs of >memory just to be "lightweight"?!!?? Spoken like a true user. It takes 150 lbs of bone and goo to implement the lightweight (1 or 2 lbs) process known as your brain. The O.S. takes a lot of memory. The PROCESSES you can run are light-weight. Big difference. To all those who think OS/2 is "missing" something by not having (gag puke retch) fork, I say this: *pppppppffffffffffftttttttttttttt* On a more mature side, fork is a very BAD way of implementing process creation. Why the heck should the child look like the parent? You want a copy of some of the data? Do an initial Send once the child is created. Fork is the biggest resource waste in existence. Then again, it's a UNIXism, so that isn't a big surprise. Back to OS/2: There is nothing wrong with OS/2, if you want all that functionality. WHY you'd want all that functionality, of course, is what your IBM rep has to tell you. Something to do with increasing memory sales, I think. craig -- Craig Eisler, Applied Math, University of Waterloo "Either way, I'm afraid to try it" - Calvin.
kc@rna.UUCP (Kaare Christian) (05/22/89)
In article <2332@water.waterloo.edu>, cgeisler@water.waterloo.edu (Craig Eisler) writes: > > To all those who think OS/2 is "missing" something by not having > (gag puke retch) fork, I say this: > > *pppppppffffffffffftttttttttttttt* > > On a more mature side, fork is a very BAD way of implementing process creation. > Why the heck should the child look like the parent? You want a copy of > some of the data? Do an initial Send once the child is created. Fork is > the biggest resource waste in existence. Then again, it's a UNIXism, so > that isn't a big surprise. > "An initial Send", whatever that is, must dupicate I/O connections, signal handling and other aspects of the original process' state, in order for it to be as powerful a mechanism as fork. Shared data is not the only issue. In a virtual memory environment, with copy on write being a standard aspect of most shared objects, a fork can be a low cost operation. (True, way back when, you really had to make a copy. Today you make a new proc table entry.) Forks make it easy to have pipes (cheapo, flexible ipc), they make it easy for things like the shell (or any interactive process) to wait in the background for their offspring to finish, without mucking up the state (I/O position, control modes) of the shared I/O connections. Unix is still the only system that allows most programs to work together easily, using ad hoc connections. Fork is an essential part of that flexibility. Fork's omission from OS/2 is more a reflection of OS/2 trying to be unlike UNIX, than a reflection that fork itself is bad. (This is not to say that OS/2 threads are bad. It is nice to have a range of choices.) And now a few numbers. How fast is "fast enough" for fork? The simple program shown below produced the following numbers on the following machines/configurations. uVAXii BSD/XINU 4.3 15ms/fork Sun 3/260 OS 4.01 35ms/fork Sun 3/50 OS 4.01 65ms/fork Now 35 ms *is* a long time, but it seems to me that you are getting a lot for those milliseconds. For example, if I were to set up a 'grep | awk | sed | pr' sort of pipeline, the fork overhead there would be something like 140 ms (on the 260), which is pretty trivial compared to the time spent exec'ing, processing, reading files, passing data in pipes, etc. *AND*, the pipeline mentioned above is ad hoc, the designers of the individual programs didn't have to plan ahead for it. Thread techniques won't, I suspect, be so flexible. And now for the source: /* time forks */ #include <sys/types.h> #include <sys/wait.h> #define NFORKS 1000 main() { time_t start, finish; /* times */ int firstpid, lastpid; /* pids */ int i; time(&start); if (!(firstpid = fork())) exit(0); else wait((union wait *)0); for(i=0;i<(NFORKS-2);i++) if (!fork()) exit(0); else wait((union wait *)0); if (!(lastpid = fork())) exit(0); else wait((union wait *)0); time(&finish); if (finish == start) /* don't divide by zero below */ finish++; printf("Forks: first child pid %d, last child pid %d\n", firstpid, lastpid); printf("%ld secs for %d fork system calls. (%g sec/call)\n", finish-start, NFORKS, (double)(finish-start)/(double)NFORKS); } Kaare Christian kc@rna.rockefeller.edu