run a command in background in C

[askmore]

Could any one tell me what is the best way to run a command in
background in C?

I have tried something like the following:

system("perl t.pl &");

It works fine for the system call, but I noticed that there is a
problem with the server socket I created right before the system call,
I couldn't close that socket anymore after the system call. If I remove
the "&" in the system call, the code works fine. (I am working on a
redhat linux system)

Can anyone share some light on it?

Thanks.

[dandelion]

"askmore" <ya**@teragram.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...

Could any one tell me what is the best way to run a command in
background in C?

I have tried something like the following:

system("perl t.pl &");

It works fine for the system call, but I noticed that there is a
problem with the server socket I created right before the system call,
I couldn't close that socket anymore after the system call. If I remove
the "&" in the system call, the code works fine. (I am working on a
redhat linux system)

Can anyone share some light on it?
This is off topic for comp.lang.c

<OT>
http://manpage.org/cgi-bin/man/man2html?query=system
http://manpage.org/cgi-bin/man/man2html?3+fork
http://manpage.org/cgi-bin/man/man2html?3+exec

In the case of a fork/exec on linux, open Filedescriptors (which includes
sockets) are inherited by the child process.

In the first case (with '&') the parent process will not wait for the child
to terminate. Therefore the Filedescripor for the socket you opened, is
referenced by *two* processes, and hence cannot be closed.

In the second case (w/o '&') the parent process will wait(3) for the child
to terminate (The system() call will block) and hence, when your parent
process tries to close the socket in question, it will be the sole process
referencing it. Hence the call succeeds.
</OT>
Thanks.

De nada.

[Keith Thompson]

"askmore" <ya**@teragram.com> writes:

Could any one tell me what is the best way to run a command in
background in C?

Not here. C has no concept of "background" (such things are often
implemented in C, but they're not part of the language). Try a
newsgroup specific to your system, perhaps comp.unix.programmer

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[CBFalconer]

askmore wrote:

Could any one tell me what is the best way to run a command in
background in C?

I have tried something like the following:

system("perl t.pl &");

It works fine for the system call, but I noticed that there is a
problem with the server socket I created right before the system call,
I couldn't close that socket anymore after the system call. If I remove
the "&" in the system call, the code works fine. (I am working on a
redhat linux system)

Can anyone share some light on it?

Probably, but not here. Commands, background, servers, sockets
have nothing to do with the portable C language. Find a group that
deals with your particular system.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson

[askmore]

Thanks for all your help, just wondering is there a way to run the
command in background and close the socket appropretely?

[Hariprasad Govardhanam]

askmore wrote:

Thanks for all your help, just wondering is there a way to run the
command in background and close the socket appropretely?

Yes, Why don't you try using two different threads? One thread tries to
run the command and another thread runs the normal program.

[dandelion]

"Hariprasad Govardhanam" <ha*******************@gmail.com> wrote in message
news:11*********************@f14g2000cwb.googlegro ups.com...

askmore wrote:

Thanks for all your help, just wondering is there a way to run the
command in background and close the socket appropretely?

Yes, Why don't you try using two different threads? One thread tries to
run the command and another thread runs the normal program.

<OT>
That would not help, since threads are implemented using lightweight
processes. I.e. a thread is a
process, too.

The "proper" answer is simply not to share the socket, i.e. open it after
your fork-exec, or close it
by when you are sure the child has terminated.
</OT>

[CBFalconer]

Hariprasad Govardhanam wrote:

askmore wrote:

Thanks for all your help, just wondering is there a way to run
the command in background and close the socket appropretely?

Yes, Why don't you try using two different threads? One thread
tries to run the command and another thread runs the normal
program.

Thread? I see no thread here. Please point out where one is
mentioned in the Bible, otherwise known as K & R or in N869 or in
"The Standard".

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson

[Keith Thompson]

"askmore" <ya**@teragram.com> writes:

Thanks for all your help, just wondering is there a way to run the
command in background and close the socket appropretely?

We don't know, and if someone posts an off-topic answer we can't check
whether it's accurate. You'll get much better information if you ask
in an appropriate newsgroup, probably comp.unix.programmer.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[askmore]

Thanks all for your kindly response and sorry about off-topic here.

The reason I choose fork/exec is that I would like to have the perl
script running in the background even after the user kills the main
program. I know this is a rare usage, but I have no choice here. :-(