Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.linux.development.apps > #93
| 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 | Next — Previous in thread | Next in thread | Find similar
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