Groups > comp.os.linux.development.apps > #94

Re: posix_spawnp never fails

From	Rainer Weikusat <rweikusat@mssgmbh.com>
Newsgroups	comp.os.linux.development.apps
Subject	Re: posix_spawnp never fails
Date	2011-04-22 18:02 +0100
Message-ID	<87liz25iej.fsf@sapphire.mobileactivedefense.com> (permalink)
References	(4 earlier) <b0433a28-7773-4f1e-86e3-99ba5a8d1fbc@a21g2000prj.googlegroups.com> <1bsjtbihed.fsf@snowball.wb.pfeifferfamily.net> <26c2e620-dcc5-481d-8a33-d543c55f32d2@n2g2000prj.googlegroups.com> <1bmxjj9vb8.fsf@snowball.wb.pfeifferfamily.net> <e25827e6-bda1-475d-b528-feb902337c43@r35g2000prj.googlegroups.com>

Show all headers | View raw

Peter <excessphase@gmail.com> writes:
> On Apr 21, 1:57 pm, Joe Pfeiffer <pfeif...@cs.nmsu.edu> wrote:
>> posix_spawnp() isn't a kernel call:  it's in the C library.  It calls
>> fork() to create a new process and returns the new process ID to the
>> caller.
>>
>> Meanwhile, the child goes off and tries to execute the execvp(), which
>> fails.  The child process now has no way to communicate with the parent,
>> except by terminating with a non-zero exit status.  Which it does.
>
>
> There are ways to communicate errno returned by execvp() to the parent
> process. I've been doing this since 1996 I think. In user-mode code!

The obvious idea would be to use a pipe with FD_CLOEXEC set and block
the parent process on the read end of the pipe. Either the exec
succeeds, then, the pipe will become readable because of the EOF
condition or the error code is written to it. So far, I have never
used a construction like that, obtaining the exit status whenever the
process exited without blocking the invoker is usually what I
want/need in code written by me.

Back to comp.os.linux.development.apps | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

posix_spawnp never fails Peter <excessphase@gmail.com> - 2011-04-20 07:38 -0700
  Re: posix_spawnp never fails Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-04-20 16:17 +0100
  Re: posix_spawnp never fails David Schwartz <davids@webmaster.com> - 2011-04-20 15:37 -0700
    Re: posix_spawnp never fails Peter <excessphase@gmail.com> - 2011-04-21 09:15 -0700
      Re: posix_spawnp never fails Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-04-21 18:12 +0100
        Re: posix_spawnp never fails Peter <excessphase@gmail.com> - 2011-04-21 11:25 -0700
          Re: posix_spawnp never fails Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-04-21 12:33 -0600
            Re: posix_spawnp never fails Peter <excessphase@gmail.com> - 2011-04-21 12:49 -0700
              Re: posix_spawnp never fails Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-04-21 14:57 -0600
                Re: posix_spawnp never fails Peter <excessphase@gmail.com> - 2011-04-21 14:09 -0700
                Re: posix_spawnp never fails Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-04-21 16:31 -0600
                Re: posix_spawnp never fails Richard Kettlewell <rjk@greenend.org.uk> - 2011-04-22 11:25 +0100
                Re: posix_spawnp never fails Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-04-22 18:02 +0100
              Re: posix_spawnp never fails Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-04-22 17:58 +0100
      Re: posix_spawnp never fails Peter <excessphase@gmail.com> - 2011-04-21 10:25 -0700
      Re: posix_spawnp never fails David Schwartz <davids@webmaster.com> - 2011-04-25 16:57 -0700

csiph-web