Unix/Linux Go Back    


Programming Post questions about C, C++, Java, SQL, and other programming languages here.

Question about execl, replacing process's contents

Programming


Tags
execl, fork, process

Closed    
 
Thread Tools Search this Thread Display Modes
    #1  
Old Unix and Linux 12-17-2016
SirSalt SirSalt is offline
Registered User
 
Join Date: Dec 2016
Last Activity: 16 January 2017, 12:21 PM EST
Location: Southeast Iowa
Posts: 6
Thanks: 5
Thanked 0 Times in 0 Posts
Unix or Linux Question Question about execl in C, replacing process's contents

I'm reading Operating Systems in Depth by Thomas W. Doeppner, and I have a question about execl. He says it's called after fork(), and that it replaces the text (code) of the current process and replaces it with the code of the new program. But that doesn't make sense to me.

Does that mean process A forks itself and its copy is process B, but process A's code is gone, and in its place is the code from process B?

OR does that mean process A forks itself and its copy is process B; process B loads a program into its text section, and now process B's text section is gone and in its place is the program it loaded?

Edit: I realize I forgot to mention the language the author uses in his examples is C

Last edited by SirSalt; 12-17-2016 at 06:08 PM..
Sponsored Links
    #2  
Old Unix and Linux 12-17-2016
jim mcnamara jim mcnamara is offline Forum Staff  
...@...
 
Join Date: Feb 2004
Last Activity: 26 September 2017, 12:17 PM EDT
Location: NM
Posts: 11,187
Thanks: 561
Thanked 1,095 Times in 1,011 Posts
Please note: This is simplified! when you read the man page for exec or fork it goes into lots of technical details. This is how I used to teach this to OS students as a high level peek. Start with a simplified model and then build on it.

Call the parent "A"

After a fork() call you now have two processes, which are identical copies (a little over simplified), A the parent and "B" the child.

If B calls execl() it clears everything out of B's memory, loads new memory and then runs.
You now have two threads of execution, A and B. Otherwise B is running the same code as A see #2 below.

The parent A has three choices:

1. most times it calls wait() to wait until the child ends. It will receive the SIGCHLD signal to let it know the status of the child. Know that the child can write to STDOUT, STDERR, and read from STDIN. The return value of the wait() call tells the parent things went ok or not ok.

2. Parent can chug along doing something else, checking periodically for termination of the child. Usually in this case the child is running a function that the parent called for it to run. Kind of like sending your kid to the store while you cook dinner. This often involves IPC (interprocess communication calls) somewhat like making your kid take a cell phone with her.

3. The parent can call exit(). If the child then calls setsid() it takes over being in charge of things like the existing tty it inherited from the parent. And possibly other objects in memory. Often lots of objects.

#1 is mostly what happens when you run a command.

#2 is what happens when the main process wants to run extra concurrent threads of execution, for example in shell scripts. It is very common on database servers. Used for efficiency usually.
When you learn about shared libraries you will understand one of the main efficiencies of this.

#3 is how to start a daemon - another name for a service like ftpd, which has no connected tty. Note the d on ftpd - means daemon. What you see:After you start a service your connection to the new program terminates and you go back to the command line prompt. You actually forked a child ("B"), which then forked the service process (call it process "C") using the same code as the parent and then the parent "B" died. C never calls setsid() id it wants to run as a detached process like a service. And since "B" died you go back to the command line.

There are variations on this but you now have the basics.

Last edited by jim mcnamara; 12-17-2016 at 07:32 PM..
The Following User Says Thank You to jim mcnamara For This Useful Post:
SirSalt (12-17-2016)
Sponsored Links
    #3  
Old Unix and Linux 12-18-2016
SirSalt SirSalt is offline
Registered User
 
Join Date: Dec 2016
Last Activity: 16 January 2017, 12:21 PM EST
Location: Southeast Iowa
Posts: 6
Thanks: 5
Thanked 0 Times in 0 Posts
Alright, thank you for clarifying that Linux

---------- Post updated 12-18-16 at 09:20 PM ---------- Previous update was 12-17-16 at 10:28 PM ----------

As I meditated on what you said, I thought of something. In your #3 explanation, would the tty be process "A"? Or would the tty in your example be process "B"? I guess I have a slight and subtle confusion about using "fork" and "forked" in the verb context. When you said "You actually forked a child ("B")", was forking the child a result of calling fork() in process "A", or calling fork() in process "B"? I hope you can see what I'm getting at here. :P
    #4  
Old Unix and Linux 12-19-2016
Don Cragun's Unix or Linux Image
Don Cragun Don Cragun is offline Forum Staff  
Administrator
 
Join Date: Jul 2012
Last Activity: 26 September 2017, 8:18 AM EDT
Location: San Jose, CA, USA
Posts: 10,509
Thanks: 544
Thanked 3,676 Times in 3,136 Posts
Quote:
Originally Posted by SirSalt View Post
Alright, thank you for clarifying that Linux

---------- Post updated 12-18-16 at 09:20 PM ---------- Previous update was 12-17-16 at 10:28 PM ----------

As I meditated on what you said, I thought of something. In your #3 explanation, would the tty be process "A"? Or would the tty in your example be process "B"? I guess I have a slight and subtle confusion about using "fork" and "forked" in the verb context. When you said "You actually forked a child ("B")", was forking the child a result of calling fork() in process "A", or calling fork() in process "B"? I hope you can see what I'm getting at here. :P
In #3, A calls fork(). At that point you have processes A and B. Then B calls fork(). At that point you have processes A, B, and C all running the same instructions. Then B calls exit() leaving you with processes A and C running. Then C calls execl() (or another function from the exec family) to replace the instructions C was running with the instructions needed to run the daemon. At that point you then have A running the code it was running and you have C running your daemon.

Note that since C was a child of B and B exited, A cannot use wait() to determine whether or not C is still running and cannot retrieve the exit status of C using wait(). (Grandparents do not become the parents of their children's orphaned children when their children die before their grandchildren.)
The Following User Says Thank You to Don Cragun For This Useful Post:
SirSalt (12-19-2016)
Sponsored Links
    #5  
Old Unix and Linux 12-19-2016
SirSalt SirSalt is offline
Registered User
 
Join Date: Dec 2016
Last Activity: 16 January 2017, 12:21 PM EST
Location: Southeast Iowa
Posts: 6
Thanks: 5
Thanked 0 Times in 0 Posts
Thanks, Don. That makes sense now.
Sponsored Links
Closed

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Linux More UNIX and Linux Forum Topics You Might Find Helpful
Thread Thread Starter Forum Replies Last Post
[Quick question]Problem with execl and GREP pfpietro UNIX for Dummies Questions & Answers 4 09-02-2012 11:39 AM
problem using execl to start a tftp process JoC UNIX for Dummies Questions & Answers 2 02-01-2012 12:21 PM
replacing text with contents from another file amoeba Shell Programming and Scripting 3 02-04-2009 11:12 PM
Replacing contents in a file from multiple programmes tosatesh Shell Programming and Scripting 1 09-02-2008 07:04 PM
replacing contents of files from a bash script HumanBeanDip Shell Programming and Scripting 2 09-13-2002 02:42 PM



All times are GMT -4. The time now is 02:02 PM.