qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] build failure with coroutine-gthread


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] build failure with coroutine-gthread
Date: Wed, 10 Aug 2011 10:14:08 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

On Tue, Aug 09, 2011 at 05:28:17PM +0000, Blue Swirl wrote:
> On Mon, Aug 8, 2011 at 9:29 AM, Stefan Hajnoczi <address@hidden> wrote:
> > On Mon, Aug 8, 2011 at 10:01 AM, Aneesh Kumar K.V
> > <address@hidden> wrote:
> >>
> >>
> >>  LINK  qemu-ga
> >> coroutine-gthread.o: In function `coroutine_init':
> >> /home/opensource/sources/qemu/qemu-upstream/coroutine-gthread.c:39: 
> >> undefined reference to `g_thread_init'
> >> collect2: ld returned 1 exit status
> >>
> >> The below patch fix the failure.  I also added the patch in the VirtFS
> >> pull request.
> >
> > It appears coroutine-core v7 was merged instead of v8.  The
> > differences are minor:
> >  * Bisectability: introduce gthread implementation before ucontext/fibers
> >  * Depend on gthread, not just glib, for multithreaded programming
> >
> > Here is the patchwork link to the gthread dependency patch in case a
> > committer wants to merge it immediately:
> > http://patchwork.ozlabs.org/patch/106810/
> 
> Coroutines only need gthreads when both ucontext and win32 versions
> are unavailable. This is handled better by my patch:
> http://lists.nongnu.org/archive/html/qemu-devel/2011-08/msg00998.html

Instead of adding more conditions around glib we should unconditionally
depend on it.  Dependencies always have an associated cost but I intend
to use glib instead of reimplementing platform abstractions and common
data structures.

The cost of maintaining non-emulation/non-virtualization code isn't
worth avoiding the dependency.  In fact I wish glib provided coroutines
so we didn't need to implement them ourselves.

Stefan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]