On 01/27/2012 01:39 PM, Alex Barcelo wrote:
I have read that one of the reasons for using makecontext is that it
saves the signal state. But there also exist functions like
"sigsetjmp" and "siglongjmp" which can be used to jump around the
coroutines while preserving signal masks.
I have a patch that uses sigsetjmp and siglongjmp instead of
makecontext and getcontext (and all the ucontext stuff), and it
*seems* to work... but I'm not sure if it works "by accident" (not
sure what I'm doing to the stack, not sure what I should be doing to
the stack).
You can post it, don't worry. I'm curious how you are switching stacks
when creating the coroutine.
I will test more, but first I wanted to ask a little bit
for advice and comments. (Well, I have to admit it: the only benchmark
I have done is "qemu-img create -f qcow2 imgfile.qcow2 5G"... an
extremely poor test, but enough to see if something works at all).
Booting a guest (even a raw image will do) is a decent smoke test.
On a related side note, this is not very well-written:
/* The ucontext functions preserve signal masks which incurs a system call
* overhead. setjmp()/longjmp() does not preserve signal masks but only
* works on the current stack. Since we need a way to create and switch to
* a new stack, use the ucontext functions for that but setjmp()/longjmp()
* for everything else.
*/
[coroutine-ucontext.c, static Coroutine *coroutine_new(void)]
Because it is not clear (IMHO) why are the exact reasons for not using
setjmp and longjmp. Is it because the signal masks? Or is it (also?)
because the "only works on the current stack"?
It's because you have to create a new stack for the new coroutine.
makecontext does it for you; you can later use it with setcontext.
Anything else (getcontext+setcontext, setjmp+longjmp,
sigsetjmp+siglongjmp) will only work on an existing stack.
But which system call are we talking about?
sigprocmask, which is invoked by sigsetjmp/siglongjmp and also
getcontext/setcontext. That's what we want to avoid.
Paolo
