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

[Anthony Liguori <aliguori@us.ibm.com>]

On 05/09/2012 03:46 PM, Peter Maydell wrote:
> On 9 May 2012 21:11, Jan Kiszka<jan.kiszka@siemens.com>  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
>