[Top] [All Lists]

Re: system() function

To: "Siders, Keith" <>
Subject: Re: system() function
From: "Justin Carlson" <>
Date: 30 May 2002 11:42:01 -0700
Cc: "Linux-Mips (E-mail)" <>
In-reply-to: <7DF7BFDC95ECD411B4010090278A44CA379B17@ATVX>
References: <7DF7BFDC95ECD411B4010090278A44CA379B17@ATVX>
On Thu, 2002-05-30 at 09:01, Siders, Keith wrote:
> I was planning to use system() to invoke a shell and launch a script.
> However it appears that this causes the parent process to terminate. A note
> in Linux Programming Bible (Goerzen, 2000) says to never invoke a shell or
> use the system() function. Having looked at fork() and exec(), these will
> require obscene amounts of memory and overhead (for an embedded box).

I'm not sure that fork() qualifies as an "obscene amount of overhead". 
That may have been true before copy-on-write, but the only thing vfork()
saves you with respect to fork() is page table construction, which is
not particularly memory or processor intensive.

> I've
> also looked at vfork() and execve(), which looks like it will do what I
> want. So do I do the vfork()/execve() pair, or is there a better way? And
> would sigaction() handling be the way to pass progress information from the
> child back to the parent process?

As a personal preference, I dislike vfork() since it's pretty
nonstandard in its behaviour on linux.  Generally, though, it sounds
like maybe you'd benefit from a copy  of Kernighan & Pike's _The Unix
Programming Environment_.  There are more ways to do interprocess
communication than you can shake a stick at, and which one is "right"
for you depends largely on your specific application.  Signals is a
reasonable way (though if you vfork() you won't be able to handle
signals in your parent concurrent with the child running...).  There are
also named pipes, shared memory, SysV messaging...


<Prev in Thread] Current Thread [Next in Thread>