On Wed, Mar 06, 2019 at 10:19:59AM +, Stefan Hajnoczi wrote:
> On Fri, Feb 22, 2019 at 11:14:09AM +0800, Peter Xu wrote:
> > Comments welcomed. Thanks,
> >
> > Peter Xu (4):
> > iothread: replace init_done_cond with a semaphore
> > iothread: create the gcontext onconditionally
> > iothr
On Fri, Feb 22, 2019 at 11:14:09AM +0800, Peter Xu wrote:
> Comments welcomed. Thanks,
>
> Peter Xu (4):
> iothread: replace init_done_cond with a semaphore
> iothread: create the gcontext onconditionally
> iothread: create main loop unconditionally
> iothread: push gcontext earlier in th
On Fri, Feb 22, 2019 at 10:28:57AM +0100, Paolo Bonzini wrote:
> On 22/02/19 04:14, Peter Xu wrote:
> > And if this patchset can survive... how about running gcontext
> > directly in iothread_run()? I believe there could be a bit more
> > things to clean but I'll see.
>
> Do you mean instead of a
On 22/02/19 04:14, Peter Xu wrote:
> And if this patchset can survive... how about running gcontext
> directly in iothread_run()? I believe there could be a bit more
> things to clean but I'll see.
Do you mean instead of aio_poll? The problem is that GMainContext is
quite a bit slower than aio_p
When I first read the iothread code, the gcontext confused me for
quite a while. Meanwhile, I've been tackling with some races due to
this complexity as well. How much we'll pay for creating the gcontext
unconditionally? Do we really need this flexibitily (or is it really
a flexibility after all
