From: Paolo Bonzini <pbonzini@redhat.com>
To: "Daniel P. Berrange" <berrange@redhat.com>
Cc: "Anthony Liguori" <aliguori@us.ibm.com>,
"Stefan Hajnoczi" <stefanha@linux.vnet.ibm.com>,
"Michael Tokarev" <mjt@tls.msk.ru>,
qemu-devel@nongnu.org, Lluís <xscript@gmx.net>,
"Blue Swirl" <blauwirbel@gmail.com>,
"Stefan Weil" <weil@mail.berlios.de>,
"Hannes Reinecke" <hare@suse.de>,
"Wenchao Xia" <xiawenc@linux.vnet.ibm.com>
Subject: Re: [Qemu-devel] [RFC] introduce a dynamic library to expose qemu block API
Date: Fri, 20 Jul 2012 13:53:16 +0200 [thread overview]
Message-ID: <500946AC.2040407@redhat.com> (raw)
In-Reply-To: <20120720113830.GH31455@redhat.com>
Il 20/07/2012 13:38, Daniel P. Berrange ha scritto:
> There's two aspects to it. First we forbid use of malloc/free/realloc
> in favour of an alternative set of APIs designed such that we can get
> compile time errors when people don't check the result for NULL.
>
> http://berrange.com/posts/2008/05/23/better-living-through-api-design-low-level-memory-allocation/
>
> This has been very successful in ensuring code checks for OOM correctly.
> Second there is a mode in our test suites where you can run under
> simulated OOM - it runs once to count the total set of mallocs in the
> test, and then re-run it 'n' times failing each malloc in turn and
> verifying that we correctly report the OOM error condition.
Does it fail each malloc in turn, or does it fail each malloc "above X
bytes" after the Y-th? Because the latter is what you actually get in
practice, and it seriously hampers your recovery capabilities.
Right now, we always use g_malloc and abort on failure, but we could
replace it with g_try_malloc in specific large allocation cases, where
large could even be not that large, for example around 64K.
Paolo
next prev parent reply other threads:[~2012-07-20 11:53 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-09 8:54 [Qemu-devel] [RFC] introduce a dynamic library to expose qemu block API Wenchao Xia
2012-07-09 9:13 ` Paolo Bonzini
2012-07-10 5:04 ` Wenchao Xia
2012-07-10 7:17 ` Paolo Bonzini
2012-07-13 9:16 ` Stefan Hajnoczi
2012-07-13 9:51 ` Paolo Bonzini
2012-07-13 11:33 ` Paolo Bonzini
2012-07-13 15:03 ` Michael Tokarev
2012-07-13 15:17 ` Blue Swirl
2012-07-13 17:07 ` Stefan Weil
2012-07-13 22:55 ` Lluís Vilanova
2012-07-16 10:39 ` Stefan Hajnoczi
2012-07-23 11:55 ` Lluís Vilanova
2012-07-23 12:09 ` Paolo Bonzini
2012-07-24 9:33 ` Lluís Vilanova
2012-07-16 8:16 ` Wenchao Xia
2012-07-16 8:19 ` Paolo Bonzini
2012-07-18 8:51 ` Wenchao Xia
2012-07-18 9:03 ` Paolo Bonzini
2012-07-18 15:28 ` Kevin Wolf
2012-07-18 9:41 ` Stefan Hajnoczi
2012-07-18 10:42 ` Paolo Bonzini
2012-07-18 12:50 ` Stefan Hajnoczi
2012-07-18 13:51 ` Andreas Färber
2012-07-18 13:55 ` Kevin Wolf
2012-07-18 13:58 ` Daniel P. Berrange
2012-07-18 14:02 ` Paolo Bonzini
2012-07-18 14:12 ` Daniel P. Berrange
2012-07-18 15:23 ` Kevin Wolf
2012-07-18 15:35 ` Daniel P. Berrange
2012-07-19 11:37 ` Paolo Bonzini
2012-07-20 11:38 ` Daniel P. Berrange
2012-07-20 11:53 ` Paolo Bonzini [this message]
2012-07-23 18:15 ` Blue Swirl
2012-07-25 8:08 ` Wenchao Xia
2012-07-09 9:27 ` Daniel P. Berrange
2012-07-10 5:37 ` Wenchao Xia
2012-07-10 7:18 ` Paolo Bonzini
2012-07-13 9:12 ` Stefan Hajnoczi
2012-07-13 9:16 ` Daniel P. Berrange
2012-07-13 9:47 ` Stefan Hajnoczi
2012-07-16 7:48 ` Wenchao Xia
2012-07-09 14:36 ` Christoph Hellwig
2012-07-10 5:42 ` Wenchao Xia
2012-07-13 9:13 ` Stefan Hajnoczi
2012-07-13 9:27 ` Christoph Hellwig
2012-07-13 9:43 ` Stefan Hajnoczi
2012-07-13 10:42 ` Kevin Wolf
2012-07-13 10:55 ` Christoph Hellwig
2012-07-13 11:19 ` Kevin Wolf
2012-07-16 7:55 ` Wenchao Xia
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=500946AC.2040407@redhat.com \
--to=pbonzini@redhat.com \
--cc=aliguori@us.ibm.com \
--cc=berrange@redhat.com \
--cc=blauwirbel@gmail.com \
--cc=hare@suse.de \
--cc=mjt@tls.msk.ru \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@linux.vnet.ibm.com \
--cc=weil@mail.berlios.de \
--cc=xiawenc@linux.vnet.ibm.com \
--cc=xscript@gmx.net \
/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.