qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Alex Barcelo <abarcelo@ac.upc.edu>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Kevin Wolf <kwolf@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v2 0/3] New sigaltstack backend for coroutine
Date: Wed, 7 Mar 2012 23:44:39 +0100	[thread overview]
Message-ID: <CAFKAgTdBcm77goqPCoXnvLtyaUgoLB4c6qZgKdxSgTqYex3dbA@mail.gmail.com> (raw)
In-Reply-To: <CAFEAcA8+zmHOu9dFF4owenOfTJEv6=nnPvy9oaaZykiMmAQJGA@mail.gmail.com>

On Wed, Mar 7, 2012 at 23:17, Peter Maydell <peter.maydell@linaro.org> wrote:
> On 7 March 2012 22:01, Alex Barcelo <abarcelo@ac.upc.edu> wrote:
>> Is this patch okay? The first version had some comments, and now the
>> v2 has been a bit too silent, not sure if that's a good sign or a bad
>> sign.
>
> Did you see the comment I added to an earlier thread regarding
> FORTIFY_SOURCE?

Sorry about that! Yes, I got the comment mixed between some other
threads, and now I was checking and didn't remember it.

About the FORTIFY_SOURCE... I don't know very well what does that mean
and what it does, I kept it from the ucontext code without thinking a
lot (irresponsibly? yes, maybe a bit).

> I think in general my opinion is swinging round to:
>  * coroutines are a portability nightmare
agreed ;)
>  * so we should either (a) ideally avoid them altogether
seems better the coroutines than state machines on every I/O process
>   or (b) defer to GNU Pth to do the hard work
My first impression was that Portable Threads is not the same as
coroutines (as the actual qemu uses coroutines). But then, thinking a
bit more about them... maybe GNU Pth can be used as a backend in some
simple way. Well, I suppose I can check them a bit deeper :)

But, moving into libpth means a to be (absolutely?) dependent on a new
library (although it's a very portable one, more portable than the
actual code). Not sure what I would do (if it was my choice) with the
glib implementation... Is there some roadmap involving coroutines and
sync/async I/O? Is this library a problem?

  reply	other threads:[~2012-03-07 22:45 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-28 11:25 [Qemu-devel] [PATCH v2 0/3] New sigaltstack backend for coroutine Alex Barcelo
2012-02-28 11:25 ` [Qemu-devel] [PATCH v2 1/3] coroutine: adding sigaltstack method (.c source) Alex Barcelo
2012-02-28 11:25 ` [Qemu-devel] [PATCH v2 2/3] coroutine: adding configure choose mechanism for coroutine backend Alex Barcelo
2012-02-28 11:25 ` [Qemu-devel] [PATCH v2 3/3] coroutine: adding configure option for sigaltstack " Alex Barcelo
2012-03-07 22:01 ` [Qemu-devel] [PATCH v2 0/3] New sigaltstack backend for coroutine Alex Barcelo
2012-03-07 22:17   ` Peter Maydell
2012-03-07 22:44     ` Alex Barcelo [this message]
2012-03-07 23:03       ` Peter Maydell
2012-03-08 10:15       ` Stefan Hajnoczi
2012-03-09 17:22 ` Kevin Wolf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAFKAgTdBcm77goqPCoXnvLtyaUgoLB4c6qZgKdxSgTqYex3dbA@mail.gmail.com \
    --to=abarcelo@ac.upc.edu \
    --cc=kwolf@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).