Hi,

I want to make a system() call, but do not wait for completition.
What can I do? One solution would be to fork() and system in the child
thread, then use a sigchld handler for removing zombie processes.

Is there any std functions that do this?

--
-Gernot
int main(int argc, char** argv) {printf
("%silto%c%cf%cgl%ssic%ccom%c", "ma", 58, 'g', 64, "ba", 46, 10);}

[ Post a follow-up to this message ]

"Gernot Frisch" <Me@Privacy.net> writes:

>Hi,

>I want to make a system() call, but do not wait for completition.
>What can I do? One solution would be to fork() and system in the child
>thread, then use a sigchld handler for removing zombie processes.

>Is there any std functions that do this?

posix_spawn().  (Well, it's a standard function but in a very recent
standard)

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

[ Post a follow-up to this message ]

Gernot Frisch wrote:
> Hi,
>
> I want to make a system() call, but do not wait for completition.
> What can I do? One solution would be to fork() and system in the child
> thread, then use a sigchld handler for removing zombie processes.
>
> Is there any std functions that do this?
>

system("command &");


--
Clem
"If you push something hard enough, it will fall over."
- Fudd's first law of opposition

[ Post a follow-up to this message ]

"Mr. Uh Clem" <uhclem@DutchElmSt.invalid> schrieb im Newsbeitrag
news:4561b058$0$26930$9a6e19ea@news.newshosting.com...
> Gernot Frisch wrote: 
>
> system("command &");

Excellent! Will try this at home.

[ Post a follow-up to this message ]

Gernot Frisch schrieb:

> I want to make a system() call, but do not wait for completition.
> What can I do? One solution would be to fork() and system in the child
> thread, then use a sigchld handler for removing zombie processes.

You can also "daemonize" the process by double forking. This does not
require a signal handler, since the init(8) process waits for the
subsubprocess:


pid1=fork();
if (pid1<0) {
perror("fork"); return;
}
if (pid1==0) {
/* Child */
pid2=fork();
if (pid2<0) {
perror("fork2"); _exit(2);
}
if (pid2==0) {
/* Subchild */
execlp("sh","sh","-c","cmd",NULL);
perror("exec");
_exit(1);   /* init does not care */
}
_exit(0);
}
if (pid1>0) {
/*Father */
wait(&status);    /* Waits for child pid1, subchild pid2
becomes child from init process */
}

(Untested)
Hubble.

[ Post a follow-up to this message ]

>    pid1=fork();
>    if (pid1<0) {
>         perror("fork"); return;
>    }
>    if (pid1==0) {
>         /* Child */
>         pid2=fork();
>         if (pid2<0) {
>             perror("fork2"); _exit(2);
>         }
>         if (pid2==0) {
>                /* Subchild */
>                execlp("sh","sh","-c","cmd",NULL);
>                perror("exec");
>                _exit(1);   /* init does not care */
>         }
>         _exit(0);
>     }
>     if (pid1>0) {
>           /*Father */
>           wait(&status);    /* Waits for child pid1, subchild pid2
> becomes child from init process */
>     }

so... noone needs to wait for pid2?

[ Post a follow-up to this message ]

Nope. Init will wait for it. It's now his kid.

Gernot Frisch wrote: 
>
> so... noone needs to wait for pid2?

[ Post a follow-up to this message ]

"Hubble" <reiner@huober.de> wrote, on Mon, 20 Nov 2006:

>          if (pid2==0) {
>                 /* Subchild */
>                 execlp("sh","sh","-c","cmd",NULL);

This call causes undefined behaviour.  (On some systems you
will be [un]lucky and it will do what you want.)  To be portable
every argument must have type char *:

execlp("sh","sh","-c","cmd",(char *)NULL);

--
Geoff Clare <netnews@gclare.org.uk>

[ Post a follow-up to this message ]

Geoff Clare <geoff@clare.See-My-Signature.invalid> writes:
> "Hubble" <reiner@huober.de> wrote, on Mon, 20 Nov 2006:
> 
>
> This call causes undefined behaviour.

It is not possible to 'cause' something 'undefined'. This is
especially absurd wrt behaviour of software, which is strictly
deterministic.

> (On some systems you will be [un]lucky and it will do what you
> want.)  To be portable every argument must have type char *:
>
>                   execlp("sh","sh","-c","cmd",(char *)NULL);

This is not exactly true, either. Assuming that execlp behaves like a
variadic function using the stdarg.h-macros (which isn't explicitly
defined anywhere), the type of the argument that was passed must be
compatible to the type the routine expects, otherwise, the behaviour
of the call is not defined by the relevant standard (SUS):

[...]

if type is not compatible with the type of the actual next
argument (as promoted according to the default argument
promotions), the behavior is undefined,

<URL:http://www.opengroup.org/onlinepubs...s/stdarg.h.html>

According to this standard, the last argument must be a null
pointer. A null pointer is a pointer that results from conversion of
a null pointer constant to a pointer type. If a null pointer of type
char * was expected, a null pointer of type void * could be used
instead. With an XSI-conformant implementation, any pointer type would
be compatible. NULL is a macro that expands to an implementation
defined null pointer constant, which may or may not have a pointer
type.

[ Post a follow-up to this message ]

Gernot Frisch wrote:
> Hi,
>
> I want to make a system() call, but do not wait for completition.
>
> Is there any std functions that do this?

In Linux, daemon function.

Regards,
Doina Babu

[ Post a follow-up to this message ]