Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
Again, generalizing. 1. A program forks a copy of itself. That's actually what a fork() does except on most modern VM systems rather than a copy of itself, it just sets up the appropriate maps. The pages are marked copy-on-write. The text segment remains fully shared because that is read only. The data segment (including the heap) remain shared until the parent or child write into them, causing a copy. 2. process forks a new program, which is not already running. This is a fork-exec. 2 separate calls. A whole new set of memory is allocated for the new image. Remember, the fork() causes the second process to be run, and the exec() causes a new image to be loaded for that process. Normally what is done is that the appropriate pages are mapped. You do not want to load any pages into either memory or into backing store (eg. swap area) unless necessary. There are some very different strategies, and I am not exactly sure what Linux does in detail. But, as far as the user is concerned a completely new image is loaded. 3. process forks a new program, which IS already running. Again, this is a fork()-exec(). The text segment is normally shared. The data segment is most likely not shared, but the data segment pages could be mapped until they are written to. I don't know exactly how Linux does it. 4. The shells. The shells normally do some processing before actually execing the command or program. Remember on a fork(), the child process inherits open file descriptors, some signal settings and sme other resources. The shell must perform a certain amount of cleanup. It must also set up any pipes that the user has created, so I am adding this as the fourth case. But, going back to the original question, Linux as well as some Unixes aggresssively use free memory for buffering and other things. "Derek D. Martin" wrote: > From a user's perspective, > Really, I think there are 3 cases of the fork scenario you describe: > > - process forks a copy of itself > - process forks a new program, which is not already running > - process forks a new program, which IS already running -- Jerry Feldman <gaf at blu.org> Boston Linux and Unix user group http://www.blu.org - Subcription/unsubscription/info requests: send e-mail with "subscribe", "unsubscribe", or "info" on the first line of the message body to discuss-request at blu.org (Subject line is ignored).
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |