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


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

Re: posix_spawnp never fails

Path csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!gegeweb.org!de-l.enfer-du-nord.net!feeder2.enfer-du-nord.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From Rainer Weikusat <rweikusat@mssgmbh.com>
Newsgroups comp.os.linux.development.apps
Subject Re: posix_spawnp never fails
Date Fri, 22 Apr 2011 17:58:21 +0100
Lines 72
Message-ID <87pqoe5iky.fsf@sapphire.mobileactivedefense.com> (permalink)
References <8cabb561-1598-4449-a821-6384386f36d5@z7g2000prh.googlegroups.com> <b6bd3c86-7703-4307-b530-8025f17ac186@d26g2000prn.googlegroups.com> <39f75515-532d-4350-8c02-bc999b4d1c39@f31g2000pri.googlegroups.com> <87sjtby1d3.fsf@sapphire.mobileactivedefense.com> <b0433a28-7773-4f1e-86e3-99ba5a8d1fbc@a21g2000prj.googlegroups.com> <1bsjtbihed.fsf@snowball.wb.pfeifferfamily.net> <26c2e620-dcc5-481d-8a33-d543c55f32d2@n2g2000prj.googlegroups.com>
Mime-Version 1.0
Content-Type text/plain; charset=utf-8
Content-Transfer-Encoding 8bit
X-Trace individual.net San8XmR8/qhYxpYGHWjqdwJY4NrhPu9hTiPzHEjjh8T8NSemI=
Cancel-Lock sha1:GfIoTflHR21gg6m7nCrhJt3oCRs= sha1:CK2La4F3QrubFfqZ4YvOcEDCItk=
User-Agent Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)
Xref x330-a1.tempe.blueboxinc.net comp.os.linux.development.apps:93

Show key headers only | View raw


Peter <excessphase@gmail.com> writes:
> On Apr 21, 11:33 am, Joe Pfeiffer <pfeif...@cs.nmsu.edu> wrote:

[...]

> And anyway -- nobody has told me yet, why it is not possible or not
> desirable that posix_spawnp() returns an error code in case of
> execvp fails. I can implement this!!!!

In my opinion, this is not desirable because it necessitates blocking
the thread (possibly, the single thread of a non-multithreaded
process) which forked until the newly created process has completed
its execve call. This may not be a problem in situations you usually
have to deal with but this isn't generally true.

[...]

> I quite like the interface of posix_spawnp().

I think this is rather a kludge because it employs a declarative mini
programming language with an associated runtime interpreter in order
to provide a subset of the functionality which is directly available
to an application using fork to create a new process, runs some code
there in order to prepare the environment for the new program and then
executes some file. 'Looks more like the Windows API' is no technical
advantage and not even necessarily an aesthetical one.

> But the implementation seems to have been done by the same people,
> which gave us
> * errno and

What's the problem with errno?

> * library routines returning pointer to static memory and

Absolutely fine for single-threaded processes.

> * SIGPIPE and

SIGPIPE (or a similar mechanism) is technically necessary in order to
be able to use programs with no specific code for such situations (eg,
general purpose 'processing filters') as part of pipelines or together
with 'other, bytestream-based' IPC mechanisms, usually, TCP sockets.
A program which is prepared to deal with the corresponding error
conditions can simply set the signal dispostion of SIGPIPE to SIG_IGN
and handle the EPIPE errors it gets instead like all other errors.

This is arguably beyond the technical capabilities of 'certain people
who are very much convinced to be Much More Intelligent and Capable
Than Everyone Else[tm]', namely, the guy who came up with this clever
idea:

	These tests had worked fine for a couple of years (actually at
	the time I had to fix bugs in libdbus to make them pass) but
	now one of these tests was breaking.  The disconnection was
	causing SIGPIPE to be delivered to the test.

	Again, this turned out to be due to a change to D-Bus.
	Lennart Poettering had been working on some changes to avoid
	libdbus’s awkward SIGPIPE handling and replace it with the use
	of the MSG_NOSIGNAL flag.  Unfortunately he’d missed a case in
	the authentication code.
        
        http://upstart.at/2010/12/20/the-importance-of-being-tested/

But Mr 'Give me the 169 or give me death' is nowhere near being the
limit of the sky.
        
> * no way to deal with "no more space" errors during writing to memory
> created by mmap() of a sparse file.

SIGSEGV can be handled on Linux.

Back to comp.os.linux.development.apps | Previous | NextPrevious 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