tdeepu100
asked on
How to make background processes in C?
Hi,
I have a question about running background processes in a shell. I have to run dir in the background.
My thinking for this to work is to get rid of the call to waitpid in the parent clause. Am I correct here?
Any help is appreciated
Thanks in advance
I have a question about running background processes in a shell. I have to run dir in the background.
My thinking for this to work is to get rid of the call to waitpid in the parent clause. Am I correct here?
Any help is appreciated
Thanks in advance
if(strcmp (instruction, "dir") == 0){
char* directory = (char*) malloc(strlen(command)-3);
substr(directory, command, 4, strlen(command));
char* a = (char*) malloc (strlen(directory) + 25);
a[0] = '\0';
strcpy(a, "/usr/bin/ls");
char al[3];
strcpy(al, "-al");
int status;
pid_t childPID = fork();
if (childPID == -1){
// fail clause
printf("Failed to fork.");
}
else if (childPID == 0){
//child clause
argVector[0] = a;
argVector[1] = al;
argVector[2] = directory;
argVector[3] = 0;
execve(a, argVector, environ);
exit(0);
}
else{
// parent clause
waitpid(childPID, &status, WUNTRACED);
}
}
evilrix
What are you trying to achieve? Yes removing the waitpid will stop the parent waiting on the child but if you do that how will yo know when it's done?
ASKER
I am trying to run the dir process in the background and then report the results once it gets done.
So when the dir process is running I should still be able to input different commands.
So when the dir process is running I should still be able to input different commands.
You'd be better off creating a thread to do this and in that thread use opendir() to enumerate the directory and stat() to get the details you're interested in.
Report the results how/where?
If the report is to a printer, or anything that isn't the controlling console, then just removing the waitpid is enough because it's "fire and forget."
If however, you want the controlling program to process the results, this gets more complicated (thus my question).
If the report is to a printer, or anything that isn't the controlling console, then just removing the waitpid is enough because it's "fire and forget."
If however, you want the controlling program to process the results, this gets more complicated (thus my question).
ASKER
yea im actually going for a controlling program..
any examples about that would be great!
any examples about that would be great!
I would try eviltrix's thread suggestion. Here's a resource that might help.
http://www.yolinux.com/TUTORIALS/LinuxTutorialPosixThreads.html
http://www.yolinux.com/TUTORIALS/LinuxTutorialPosixThreads.html
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
>> Do not use a thread instead of fork, you're calling execve.
I'm not sure I follow your thought process here. Maybe you could elaborate what that has to do with solving this issue using threads rather than processes?
I'm not sure I follow your thought process here. Maybe you could elaborate what that has to do with solving this issue using threads rather than processes?
exec*() substitute the entire process with a new process.
So if you are calling exec*() within a thread, your thread, and all the other thread, will terminate.
So inside your thread you should call fork() and then exec.
But between fork() and exec() there are two copies of each same process - with the same thread working. You must ensure that all other thread in the forked(), child process, do not interfere with the original process. Race condition is a great risk in this case.
Hope I am been clear, if not do not hesitate to ask.
So if you are calling exec*() within a thread, your thread, and all the other thread, will terminate.
So inside your thread you should call fork() and then exec.
But between fork() and exec() there are two copies of each same process - with the same thread working. You must ensure that all other thread in the forked(), child process, do not interfere with the original process. Race condition is a great risk in this case.
Hope I am been clear, if not do not hesitate to ask.
HappyCactus:
Wouldn't that mean that the system() call is not thread-safe? That's news to me.
I agree, though, that the time between fork() and exec() should be as short as possible (e.g., create the arguments and all needed data before forking).
Wouldn't that mean that the system() call is not thread-safe? That's news to me.
I agree, though, that the time between fork() and exec() should be as short as possible (e.g., create the arguments and all needed data before forking).
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
evilrix,
I agree with your solution! It's _the_ right solution, that should be implemented like you suggested.
I do not like call shells from inside a program - it is dangerous for various things and it must be done correctly - a bad path can subvert your program.
But I wanted to clarify why he should not call execve or fork() inside a thread.
I agree with your solution! It's _the_ right solution, that should be implemented like you suggested.
I do not like call shells from inside a program - it is dangerous for various things and it must be done correctly - a bad path can subvert your program.
But I wanted to clarify why he should not call execve or fork() inside a thread.
>> But I wanted to clarify why he should not call execve or fork() inside a thread.
Understood. Thanks :)
Understood. Thanks :)