qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC PATCH 0/2] port network layer onto glib


From: Markus Armbruster
Subject: Re: [Qemu-devel] [RFC PATCH 0/2] port network layer onto glib
Date: Tue, 19 Mar 2013 10:30:34 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux)

Peter Maydell <address@hidden> writes:

> On 13 March 2013 12:34, Anthony Liguori <address@hidden> wrote:
>> AioContext is necessary for the block layer because the block layer
>> still has synchronous I/O.  I think we should aim to replace all sync
>> I/O in the long term with coroutine based I/O.
>
> I think coroutines are dreadful and we should really not be moving
> towards greater use of them. They're just really really not portable
> and they don't fit with the C language, and they're a constant source
> of problems.(For instance I have a bug I need to look into where we
> seem to hang using the gthread coroutine backend but not sigaltstack.)
>
> Use threads, or a genuinely asynchronous API, or a select/poll loop
> with callbacks, but not more coroutines please.

I disagree.

Coroutines are a perfectly pedestrian control flow construct.  Stefan
already explained why we use them, and why callbacks are not a viable
alternative when things get hairy.

Coroutines fit about as well with C as threads, namely not really.
Unfortunate, but switching to threads won't improve that aspect one bit,
just add "interesting" concurrency and performance problems to the mix.

If portable coroutines in C really was an intractable problem, the
solution could not be "no more coroutines, please", only "no coroutines,
period".  As long as we have to pay the price for coroutines anyway, I
can't see why we should deny ourselves the benefits.

C programs have been doing coroutines since forever, using either hand
coded assembly language stack switching, sigaltstack() trickery,
ucontext(), w32 fibers, or some coroutine library built on top of these.
We chose "all of the above" (except for assembly).  No wonder we got
more problems.

Some of our portability problems come from our heroic (quixotic?) quest
to keep QEMU portable to the widest range of hosts, without sacrificing
performance on any of them.  Sometimes it takes a tough man to make a
tender chicken.



reply via email to

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