Re: [Qemu-devel] [PATCH 0/3] New sigaltstack method for coroutine

[Alex Barcelo]

On Mon, Feb 13, 2012 at 15:51, Peter Maydell <address@hidden> wrote:
> On 13 February 2012 14:42, Alex Barcelo <address@hidden> 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).
>
> So the obvious question here is why this should be a new
> coroutine method rather than just replacing the ucontext one.

Well, you are right. I did this because I needed something for an
environment which doesn't have ucontext support[1] (and the fallback
was awful).

> Having a tricky bit of code like the coroutine implementation
> have multiple implementations is asking for the less-used
> ones to bitrot, have undetected race conditions, etc. I would
> much prefer it if we could have one standard implementation
> that was used on all (unixy) platforms.

ucontext seems the "modern good way" (as far as I have read)... but
it's not standard enough. And not very multiplatform, as I have seen.

> The ucontext implementation is problematic because makecontext
> &co aren't implemented on all platforms (ARM Linux, and I think
> at least one of the BSDs?). Is this sigaltstack approach
> workable on a strict superset of the platforms that would
> be able to use ucontext? Does it have any disadvantages that
> would mean you wouldn't want to use it as a first choice
> if you had ucontext?

This new implementation... well, it seems to work (I have done an
ubuntu installation with a cdrom and a qcow drive, which seems to use
quite a lot of coroutines). Of course I have done the coroutine-test
and it was OK. But... I wasn't confident enough to propose it as a
"mature alternative". And I don't have any performance benchmark,
which would be interesting. So, I thought that the better option would
be to send this patch to the developers as an alternative to ucontext.

The Portable Threads library use ucontext as the first variant, and
then sigaltstack as a fallback. Their comment (not sure if it's
useful)
/*
 * VARIANT 1: THE STANDARDIZED SVR4/SUSv2 APPROACH
 *
 * This is the preferred variant, because it uses the standardized
 * SVR4/SUSv2 makecontext(2) and friends which is a facility intended
 * for user-space context switching. The thread creation therefore is
 * straight-foreward.
 */

/*
 * VARIANT 2: THE SIGNAL STACK TRICK
 *
 * ...
 * The ingenious fact is that this variant runs really on _all_ POSIX
 * compliant systems without special platform kludges.  But be _VERY_
 * carefully when you change something in the following code. The slightest
 * change or reordering can lead to horribly broken code.  Really every
 * function call in the following case is intended to be how it is, doubt
 * me...
 *
 * For more details we strongly recommend you to read the companion
 * paper ``Portable Multithreading -- The Signal Stack Trick for
 * User-Space Thread Creation'' from Ralf S. Engelschall. A copy of the
 * draft of this paper you can find in the file rse-pmt.ps inside the
 * GNU Pth distribution.
 */

The Pth is capable to use sigstack if no sigaltstack is found in the
host. I have not implemented it, but should be reasonably
straightforward.

[1] In fact, I was trying to run a powerpc-crosscompiled i386-softmmu
inside a qemu-ppc linux-user (on a i386 box). And ppc linux-user
doesn't support the needed syscall for ucontext functions. So it was a
first step.