Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

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

Re: posix_spawnp never fails

Show all headers | View raw

Peter <excessphase@gmail.com> writes:
> I would like to get an error telling me that there is no such file
> in case of I'm trying to start a process from a non existent
> executable file.
> But posix_spawnp seems to always succeed.

posix_spawn is a restricted interface intended for MMU-less systems
and others of similarly feeble capabilities, eg, Oracle Solaris :->.

>  cannot use the mess of pipe/fork/exec/write(errno),
> since this seems to be not supported as I was told recently --
> "there is nothing supported which can be done in the cloned child
> process
> than execvp() or _exit()"

This looks like a botched description of vfork. There is an easy way
to deal with limitations of vfork: Don't use it. The overhead of
copying the page tables of the parent of noise, compared to the
overhead of executing a new file and vfork causes the process which
called it to stop for an essentially indeterminate time (until the
scheduler got around to running the vfork'ed child process for long
enough for it to complete and switched back to the original process).

> especiallly in multithreaded environments.

The UNIX(*)-standard does not define the behaviour of a multithreaded
process which forks and executes a function which is not defined as
async signal safe. In practice, this means that inter-thread
synchronization objects remain in the state they had at the time
of the call, eg, a locked mutex stays locked. Since only the thread
that locked a mutex is supposed to be able to unlock it and only the
thread which executed fork will be running in the new process, its
address space may contain unreleasable mutexes which chould lead to a
deadlock (eg, because the active thread in the new process calls a
stdio-routine and then blocks on an internal mutex that was locked by
another thread in the parent process). The implication is that you
either need to know what your threads are doing in order to determine if fork
can be called safely or that the thread which is going to fork must
acquire all mutexes which could be needed in the new proess before
forking.

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