Re: [Qemu-devel] [PATCH v2 0/3] New sigaltstack backend for coroutine
Am 28.02.2012 12:25, schrieb Alex Barcelo: This series of patches implements coroutines method with sigaltstack. The flow of creation and management of the coroutines is quite similar to the coroutine-ucontext.c. The way to use sigaltstack to achieve the needed stack manipulation is done in a way quite similar to the GNU Portable Threads (file pth_mctx.c, variant 2). This v2 has some corrections and improved patches, but it's essentially the same. At the moment, the default backend is ucontext (the former default method for coroutines). Alex Barcelo (3): coroutine: adding sigaltstack method (.c source) coroutine: adding configure choose mechanism for coroutine backend coroutine: adding configure option for sigaltstack coroutine backend Makefile.objs |4 + configure | 41 +- coroutine-sigaltstack.c | 334 +++ 3 files changed, 371 insertions(+), 8 deletions(-) create mode 100644 coroutine-sigaltstack.c Thanks, applied all to the block branch. Kevin
Re: [Qemu-devel] [PATCH v2 0/3] New sigaltstack backend for coroutine
On Wed, Mar 7, 2012 at 10:44 PM, Alex Barcelo abarc...@ac.upc.edu wrote: 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 Going back to callbacks is moving in the wrong direction. Instead we could take a step forward and come up with a proper threading model for QEMU and convert coroutine code to execute in worker threads. In fact, Paolo has already posted some ideas about a threaded block layer and a prototype git branch. I think this is the right approach to follow. Stefan
Re: [Qemu-devel] [PATCH v2 0/3] New sigaltstack backend for coroutine
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. Thanks sorry! On Tue, Feb 28, 2012 at 12:25, Alex Barcelo abarc...@ac.upc.edu wrote: This series of patches implements coroutines method with sigaltstack. The flow of creation and management of the coroutines is quite similar to the coroutine-ucontext.c. The way to use sigaltstack to achieve the needed stack manipulation is done in a way quite similar to the GNU Portable Threads (file pth_mctx.c, variant 2). This v2 has some corrections and improved patches, but it's essentially the same. At the moment, the default backend is ucontext (the former default method for coroutines). Alex Barcelo (3): coroutine: adding sigaltstack method (.c source) coroutine: adding configure choose mechanism for coroutine backend coroutine: adding configure option for sigaltstack coroutine backend Makefile.objs | 4 + configure | 41 +- coroutine-sigaltstack.c | 334 +++ 3 files changed, 371 insertions(+), 8 deletions(-) create mode 100644 coroutine-sigaltstack.c -- 1.7.5.4
Re: [Qemu-devel] [PATCH v2 0/3] New sigaltstack backend for coroutine
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? I think in general my opinion is swinging round to: * coroutines are a portability nightmare * so we should either (a) ideally avoid them altogether or (b) defer to GNU Pth to do the hard work -- PMM
Re: [Qemu-devel] [PATCH v2 0/3] New sigaltstack backend for coroutine
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?
Re: [Qemu-devel] [PATCH v2 0/3] New sigaltstack backend for coroutine
On 7 March 2012 22:44, Alex Barcelo abarc...@ac.upc.edu wrote: On Wed, Mar 7, 2012 at 23:17, Peter Maydell peter.mayd...@linaro.org wrote: 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). Ha. I should have read your actual patch, sorry :-) That bit of code does correctly disable a glibc sanity check which would otherwise cause this code to fail, so your patch is OK on this point. -- PMM
[Qemu-devel] [PATCH v2 0/3] New sigaltstack backend for coroutine
This series of patches implements coroutines method with sigaltstack. The flow of creation and management of the coroutines is quite similar to the coroutine-ucontext.c. The way to use sigaltstack to achieve the needed stack manipulation is done in a way quite similar to the GNU Portable Threads (file pth_mctx.c, variant 2). This v2 has some corrections and improved patches, but it's essentially the same. At the moment, the default backend is ucontext (the former default method for coroutines). Alex Barcelo (3): coroutine: adding sigaltstack method (.c source) coroutine: adding configure choose mechanism for coroutine backend coroutine: adding configure option for sigaltstack coroutine backend Makefile.objs |4 + configure | 41 +- coroutine-sigaltstack.c | 334 +++ 3 files changed, 371 insertions(+), 8 deletions(-) create mode 100644 coroutine-sigaltstack.c -- 1.7.5.4
