On 01/26/2011 03:23 PM, Stefan Hajnoczi wrote:
Both g_malloc() and g_try_malloc() are available where g_try_malloc()
returns NULL on failure. g_malloc() matches qemu_malloc() exit
behavior today but in the future it would be possible to use
g_try_malloc() for proper out-of-memory handling.
But
On Wed, Jan 26, 2011 at 3:53 PM, Anthony Liguori
wrote:
> On 01/25/2011 10:47 PM, Daniel Veillard wrote:
>>
>> On Mon, Jan 24, 2011 at 03:00:38PM -0600, Anthony Liguori wrote:
>>
>>>
>>> Both the recent I/O loop and threadlet series have me concerned that
>>> we're
>>> digging ourselves deeper int
Hi,
just a few thoughts from a qemu novice...
On Mon, Jan 24, 2011 at 03:00:38PM -0600, Anthony Liguori wrote:
> This series introduces a hard dependency on glib. The initial use is portable
> threads but I see this as just the beginning. Glib/Gobject offer many nice
> things including:
>
> -
On 01/25/2011 10:47 PM, Daniel Veillard wrote:
On Mon, Jan 24, 2011 at 03:00:38PM -0600, Anthony Liguori wrote:
Both the recent I/O loop and threadlet series have me concerned that we're
digging ourselves deeper into the NIH hole. I think it's time we look at
something radical to let us bor
On Tue, 25 Jan 2011, Anthony Liguori wrote:
> My end goal is not C++, it's to improve the device model. I haven't
> tried doing it with GObject yet but before we even get there, there's a
> lot of good we can do with glib.
I certainly agree with this.
On 01/25/2011 08:48 AM, Stefano Stabellini wrote:
On Tue, 25 Jan 2011, Gerd Hoffmann wrote:
I've spent the past few months working on C++ integration for QEMU. I'm more
convinced than ever that we desperately in need of structured object oriented
mechanisms to be successful but am pretty st
On Tue, 25 Jan 2011, Gerd Hoffmann wrote:
> > I've spent the past few months working on C++ integration for QEMU. I'm
> > more
> > convinced than ever that we desperately in need of structured object
> > oriented
> > mechanisms to be successful but am pretty strongly convinced that
> > incremen
On 01/25/2011 08:23 AM, Aurelien Jarno wrote:
On Mon, Jan 24, 2011 at 03:00:38PM -0600, Anthony Liguori wrote:
Both the recent I/O loop and threadlet series have me concerned that we're
digging ourselves deeper into the NIH hole. I think it's time we look at
something radical to let us borr
On Mon, Jan 24, 2011 at 03:00:38PM -0600, Anthony Liguori wrote:
> Both the recent I/O loop and threadlet series have me concerned that we're
> digging ourselves deeper into the NIH hole. I think it's time we look at
> something radical to let us borrow more code from existing projects instead of
On Tue, Jan 25, 2011 at 12:51:42PM +0100, Gerd Hoffmann wrote:
> On 01/24/11 22:00, Anthony Liguori wrote:
> >Both the recent I/O loop and threadlet series have me concerned that we're
> >digging ourselves deeper into the NIH hole. I think it's time we look at
> >something radical to let us borrow
On 01/24/11 22:00, Anthony Liguori wrote:
Both the recent I/O loop and threadlet series have me concerned that we're
digging ourselves deeper into the NIH hole. I think it's time we look at
something radical to let us borrow more code from existing projects instead of
reinventing everything thro
On Mon, Jan 24, 2011 at 9:00 PM, Anthony Liguori wrote:
> This series introduces a hard dependency on glib. The initial use is portable
> threads but I see this as just the beginning. Glib/Gobject offer many nice
> things including:
>
> - portable threads
> - rich data structure support
> - I
On Mon, Jan 24, 2011 at 06:24:13PM -0600, Anthony Liguori wrote:
> On 01/24/2011 03:00 PM, Anthony Liguori wrote:
> > Both the recent I/O loop and threadlet series have me concerned that we're
> > digging ourselves deeper into the NIH hole. I think it's time we look at
> > something radical to let
On 01/24/2011 03:00 PM, Anthony Liguori wrote:
Both the recent I/O loop and threadlet series have me concerned that we're
digging ourselves deeper into the NIH hole. I think it's time we look at
something radical to let us borrow more code from existing projects instead of
reinventing everything
Both the recent I/O loop and threadlet series have me concerned that we're
digging ourselves deeper into the NIH hole. I think it's time we look at
something radical to let us borrow more code from existing projects instead of
reinventing everything through trial and error.
This series introduces
15 matches
Mail list logo
