From: Tim Wright <timw@splhi.com>
To: Stephen Satchell <satch@fluent-access.com>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] gcc-3.0 warnings
Date: Mon, 26 Mar 2001 06:25:57 -0800 [thread overview]
Message-ID: <20010326062557.A1985@kochanski.internal.splhi.com> (raw)
In-Reply-To: <20010323235909.C3098@werewolf.able.es> <20010323162956.A27066@ganymede.isdn.uiuc.edu> <Pine.LNX.4.31.0103231433380.766-100000@penguin.transmeta.com> <20010323235909.C3098@werewolf.able.es> <20010323163129.B2534@kochanski.internal.splhi.com> <4.3.2.7.2.20010323170728.00b31100@mail.fluent-access.com>
In-Reply-To: <4.3.2.7.2.20010323170728.00b31100@mail.fluent-access.com>; from satch@fluent-access.com on Fri, Mar 23, 2001 at 05:16:26PM -0800
On Fri, Mar 23, 2001 at 05:16:26PM -0800, Stephen Satchell wrote:
[...]
> Really? I have a "cleanup" function that can be called during failure
> cases (and success cases -- but you didn't mention that) so that the cost
> is very low and I don't have to code ANY labels.
>
> But then again, I'm a double-pipe abuser, in that I tend to code "atomic"
> sequences as
>
> if ((a) || (b) || (c) || (d) || (e) || (f) || (g) || ... ) { something
> failed} else {it all worked!}
>
> and make sure that the failure value is non-zero for each a, b, c, d, and
> so forth.
>
Sorry, my example was too simplistic. Replace simple allocations with e.g.
allocate();
grab lock;
set flag;
allocate();
or something similar. Yes it's possible to code a state variable to remember
where you got to, or to e.g. add an extra boolean variable to indicate that
you grabbed the lock, but I'd argue that this obfuscates the code as well as
making it less efficient. It's no good looking to see if the lock has been
grabbed - if you failed at the first stage, it may still be locked by a
different CPU.
Tim
--
Tim Wright - timw@splhi.com or timw@aracnet.com or twright@us.ibm.com
IBM Linux Technology Center, Beaverton, Oregon
Interested in Linux scalability ? Look at http://lse.sourceforge.net/
"Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI
next prev parent reply other threads:[~2001-03-26 14:27 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-03-23 0:11 [PATCH] gcc-3.0 warnings J . A . Magallon
2001-03-23 0:28 ` Alan Cox
2001-03-23 0:38 ` J . A . Magallon
2001-03-23 9:29 ` Tim Waugh
2001-03-23 23:56 ` Ingo Oeser
2001-03-23 22:29 ` Bill Wendling
2001-03-23 22:34 ` Linus Torvalds
2001-03-23 22:59 ` J . A . Magallon
2001-03-24 0:31 ` Tim Wright
2001-03-24 0:42 ` Andrew Morton
2001-03-24 0:55 ` J . A . Magallon
2001-03-24 21:51 ` Tim Waugh
2001-03-24 1:16 ` Stephen Satchell
2001-03-26 14:25 ` Tim Wright [this message]
2001-03-24 5:30 ` Ion Badulescu
2001-03-23 17:12 ` Horst von Brand
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=20010326062557.A1985@kochanski.internal.splhi.com \
--to=timw@splhi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=satch@fluent-access.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox