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 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> References: <8cabb561-1598-4449-a821-6384386f36d5@z7g2000prh.googlegroups.com> <39f75515-532d-4350-8c02-bc999b4d1c39@f31g2000pri.googlegroups.com> <87sjtby1d3.fsf@sapphire.mobileactivedefense.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 Peter writes: > On Apr 21, 11:33 am, Joe Pfeiffer 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.