On 05/09/2012 04:27 PM, Peter Maydell wrote:
On 9 May 2012 21:59, Anthony Liguori<aligu...@us.ibm.com> wrote:
On 05/09/2012 03:46 PM, Peter Maydell wrote:
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.
Yeah, I agree with this sentiment...
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.
...but I would at least like us to take the position that we don't
introduce *more* users of coroutines.
I think the long term plan has been:
1) replace synchronous I/O users with coroutines + async I/O
2) promote coroutines to threads by introducing fine grain locking.
I don't think avoiding coroutines helps us along this route nor does it help
eliminate immediate users of coroutines.
I think our best strategy forward is to get rid of async I/O in the blocker
layer and in devices. Then I think we should promote coroutines as much as
possible.
Regards,
Anthony Liguori
-- PMM
