From: ebiederm@xmission.com (Eric W. Biederman)
To: Eduardo PXrez <100018135@alumnos.uc3m.es>
Cc: Marius Gedminas <mgedmin@centras.lt>, linux-kernel@vger.kernel.org
Subject: Re: fork() wait semantics
Date: 16 Oct 2002 02:38:29 -0600 [thread overview]
Message-ID: <m1u1jm3hiy.fsf@frodo.biederman.org> (raw)
In-Reply-To: <a074067cb9f2b74a80a9f9f03f0abcaa@alumnos.uc3m.es>
Eduardo PXrez <100018135@alumnos.uc3m.es> writes:
> On 2002-10-15 20:07:43 +0200, Marius Gedminas wrote:
> > On Tue, Oct 15, 2002 at 04:58:44PM +0000, Eduardo Pérez wrote:
> > > As an example consider bash. In case of fork() error the program
> > > isn't even run thus causing a fatal error. If fork() waited for
> > > resources to be available there wouldn't be any problem.
> >
> > No, thank you. This happened to me more than once (runaway fetchmail
> > plugins). An error message about a failing fork() indicates
> > immediately that I have too many processes, and I can kill them
> > (thankfully kill is a bash builtin). If bash just waited silently I
> > wouldn't know what to think.
>
> But you are talking about buggy software.
> If you software has bugs don't expect it to work properly.
>
> These fork() semantics are for non-buggy software.
Well that clinches it since there is no non-buggy software we
definitely don't want that behavior.
Eric
prev parent reply other threads:[~2002-10-16 8:34 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-15 11:55 Better fork() (and possbly others) failure diagnostics Michal Kara
2002-10-15 13:16 ` jw schultz
2002-10-15 15:46 ` Michal Kara
2002-10-16 3:11 ` jw schultz
2002-10-18 15:25 ` Pavel Machek
2002-10-15 16:58 ` fork() wait semantics Eduardo Pérez
2002-10-15 18:07 ` Marius Gedminas
2002-10-15 22:28 ` Eduardo Pérez
2002-10-16 8:38 ` Eric W. Biederman [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m1u1jm3hiy.fsf@frodo.biederman.org \
--to=ebiederm@xmission.com \
--cc=100018135@alumnos.uc3m.es \
--cc=linux-kernel@vger.kernel.org \
--cc=mgedmin@centras.lt \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.