On Wed, Mar 7, 2012 at 23:17, Peter Maydell <peter.mayd...@linaro.org> wrote: > On 7 March 2012 22:01, Alex Barcelo <abarc...@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?