qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 1.1] coroutine: Avoid ucontext usage on i386 Lin


From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 1.1] coroutine: Avoid ucontext usage on i386 Linux host
Date: Wed, 09 May 2012 15:59:49 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1

On 05/09/2012 03:46 PM, Peter Maydell wrote:
On 9 May 2012 21:11, Jan Kiszka<address@hidden>  wrote:
OK. Then what about sigaltstack (once fixed)? Is it also slower? If not,
can we converge over it?

sigaltstack is going to be significantly faster than the gthread
implementation (about the same speed as ucontext for coroutine
switch, a bit slower for coroutine creation).

It suffers from the same problem of being a code path which nobody
has seriously stress tested, though. And it does at least one thing
which is "not permitted by the standards but works anyway".

I would really hate staying with this time bomb
of broken RT signals unless someone tells me we will kick out all these
coroutines rather sooner than later.

I think that regardless of the long term choice it would be
a pretty risky decision to switch coroutine implementation
this close to release when we have the option of just using
a different signal that avoids the bug.

Longer term (ie post 1.1) I'm strongly in favour of kicking
out coroutines, because I think there clearly is no single
solid portable implementation possible. C just isn't designed
to allow them; better not to try to swim against the current.

Unfortunately, voting for code to be different doesn't actually make it 
different.

If you're volunteering to rewrite the block layer to not require coroutines (either by using a state machine or by using re-entrant threads and fixing any locking issues associated with that) that's wonderful.

But we decided to not do synchronous I/O years ago and still haven't removed it all from the tree. Coroutines got us much closer to getting rid of synchronous I/O.

Regards,

Anthony Liguori


-- PMM





reply via email to

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