[Qemu-devel] getting rid of coroutine-gthread?

[Qemu-devel] getting rid of coroutine-gthread?

[Paolo Bonzini]

Brad and Peter,

as far as I know OpenBSD and Linux/ARM were the main users of
coroutine-gthread.  Do you think we could dump it and rely on
coroutine-sigaltstack only?  The differences in signal handling of the
gthread implementation always worried me.

What versions of OpenBSD would we have to drop support for?  Is that
acceptable to you?

Paolo

Re: [Qemu-devel] getting rid of coroutine-gthread?

[Andreas Färber]

Am 11.01.2013 19:11, schrieb Paolo Bonzini:
> Brad and Peter,
> 
> as far as I know OpenBSD and Linux/ARM were the main users of
> coroutine-gthread.  Do you think we could dump it and rely on
> coroutine-sigaltstack only?  The differences in signal handling of the
> gthread implementation always worried me.
> 
> What versions of OpenBSD would we have to drop support for?  Is that
> acceptable to you?

No, I believe there is explicit code in configure to force the GThread
implementation on Mac OS X.

Andreas

Re: [Qemu-devel] getting rid of coroutine-gthread?

[Brad Smith]

On Fri, Jan 11, 2013 at 07:11:36PM +0100, Paolo Bonzini wrote:
> Brad and Peter,
> 
> as far as I know OpenBSD and Linux/ARM were the main users of
> coroutine-gthread.  Do you think we could dump it and rely on
> coroutine-sigaltstack only?  The differences in signal handling of the
> gthread implementation always worried me.
> 
> What versions of OpenBSD would we have to drop support for?  Is that
> acceptable to you?

I'm OK with this. For our ports tree I have QEMU using the sigaltstack
backend with 1.2.2 at the moment with -current.

Our official policy is to use the ports/packages wherever possible
for third-party software. For our current release (5.2) we provide
QEMU 1.1.0. For -current we have 1.2.2 at the moment and I plan on
updating to 1.3.1/1.4.0 depending on when and if 1.3.1 is released
or if 1.4.0 is released sooner I'll just skip to 1.4.0. 1.3.1 with
the back ported patch for using sem_timedwait() will require 5.2.
1.4.0 if dropping support for the gthread backend will require
-current or the next release 5.3 which we will be going into freeze
for within a month and a bit and the release will be May 1st. This
is acceptable to me. I'd prefer that QEMU wherever possible do
things properly and put the pressure on OpenBSD to do things
properly as well and have bugs fixed. I had proded the developer
working on the sigaltstack fix to get his work in and it has
been commited.

http://marc.info/?l=openbsd-cvs&m=135443183201631&w=2

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [Qemu-devel] getting rid of coroutine-gthread?

[Brad Smith]

On Fri, Jan 11, 2013 at 07:24:35PM +0100, Andreas F?rber wrote:
> Am 11.01.2013 19:11, schrieb Paolo Bonzini:
> > Brad and Peter,
> > 
> > as far as I know OpenBSD and Linux/ARM were the main users of
> > coroutine-gthread.  Do you think we could dump it and rely on
> > coroutine-sigaltstack only?  The differences in signal handling of the
> > gthread implementation always worried me.
> > 
> > What versions of OpenBSD would we have to drop support for?  Is that
> > acceptable to you?
> 
> No, I believe there is explicit code in configure to force the GThread
> implementation on Mac OS X.

That is to skip over testing for the ucontext implementation. There was
a build issue with the sigaltstack implementation but it was fixed
relatively recently.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [Qemu-devel] getting rid of coroutine-gthread?

[Peter Maydell]

On 12 January 2013 09:07, Brad Smith <brad@comstyle.com> wrote:
> On Fri, Jan 11, 2013 at 07:24:35PM +0100, Andreas F?rber wrote:
>> Am 11.01.2013 19:11, schrieb Paolo Bonzini:
>> > as far as I know OpenBSD and Linux/ARM were the main users of
>> > coroutine-gthread.  Do you think we could dump it and rely on
>> > coroutine-sigaltstack only?
>>
>> No, I believe there is explicit code in configure to force the GThread
>> implementation on Mac OS X.
>
> That is to skip over testing for the ucontext implementation. There was
> a build issue with the sigaltstack implementation but it was fixed
> relatively recently.

Yes. That configure skip code is actually broken because it skips the
test for the ucontext implementation but doesn't actually set the
coroutine_backend variable to anything, so we end up with (a)
a confusing message to the user saying just "coroutine backend"
rather than "coroutine backend foo" and (b) the gthreads backend
more by luck than judgement. Easiest fix here is probably to
replace the 'if darwin' check with an "#ifdef some-darwin-symbol
#error" in the makecontext test program (and incidentally we could
add a comment to the effect that at least some versions of MacOS
provide makecontext but make getcontext always return ENOTSUP;
I had to trawl the mailing list to find out why we did that :-))

Even if we don't drop gthreads, I think there's an argument to be
made for having sigcontext be the next backend to try after
ucontext.

-- PMM

Re: [Qemu-devel] getting rid of coroutine-gthread?

[Brad Smith]

On Sat, Jan 12, 2013 at 12:08:47PM +0000, Peter Maydell wrote:
> On 12 January 2013 09:07, Brad Smith <brad@comstyle.com> wrote:
> > On Fri, Jan 11, 2013 at 07:24:35PM +0100, Andreas F?rber wrote:
> >> Am 11.01.2013 19:11, schrieb Paolo Bonzini:
> >> > as far as I know OpenBSD and Linux/ARM were the main users of
> >> > coroutine-gthread.  Do you think we could dump it and rely on
> >> > coroutine-sigaltstack only?
> >>
> >> No, I believe there is explicit code in configure to force the GThread
> >> implementation on Mac OS X.
> >
> > That is to skip over testing for the ucontext implementation. There was
> > a build issue with the sigaltstack implementation but it was fixed
> > relatively recently.
> 
> Yes. That configure skip code is actually broken because it skips the
> test for the ucontext implementation but doesn't actually set the
> coroutine_backend variable to anything, so we end up with (a)
> a confusing message to the user saying just "coroutine backend"
> rather than "coroutine backend foo" and (b) the gthreads backend
> more by luck than judgement. Easiest fix here is probably to
> replace the 'if darwin' check with an "#ifdef some-darwin-symbol
> #error" in the makecontext test program (and incidentally we could
> add a comment to the effect that at least some versions of MacOS
> provide makecontext but make getcontext always return ENOTSUP;
> I had to trawl the mailing list to find out why we did that :-))
> 
> Even if we don't drop gthreads, I think there's an argument to be
> made for having sigcontext be the next backend to try after
> ucontext.
 
The ucontext support in OS X has been marked as deprecated, that
seems to have popped up with 10.6. No idea if it has been removed
all together since then. It was made obsolete in POSIX.1-2001.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [Qemu-devel] getting rid of coroutine-gthread?

[Kevin Wolf]

Am 11.01.2013 19:11, schrieb Paolo Bonzini:
> Brad and Peter,
> 
> as far as I know OpenBSD and Linux/ARM were the main users of
> coroutine-gthread.  Do you think we could dump it and rely on
> coroutine-sigaltstack only?  The differences in signal handling of the
> gthread implementation always worried me.
> 
> What versions of OpenBSD would we have to drop support for?  Is that
> acceptable to you?

Changing the defaults for these platforms may be a good idea, but I
actually like the option of having coroutine-gthread because it's much
friendlier to debug - gdb supports threads, but not coroutines.

Is coroutine-gthread blocking anything or is it just that you're not
entirely confident in its correctness?

Kevin

Re: [Qemu-devel] getting rid of coroutine-gthread?

[Paolo Bonzini]

Il 15/01/2013 14:18, Kevin Wolf ha scritto:
>> > Brad and Peter,
>> > 
>> > as far as I know OpenBSD and Linux/ARM were the main users of
>> > coroutine-gthread.  Do you think we could dump it and rely on
>> > coroutine-sigaltstack only?  The differences in signal handling of the
>> > gthread implementation always worried me.
>> > 
>> > What versions of OpenBSD would we have to drop support for?  Is that
>> > acceptable to you?
> Changing the defaults for these platforms may be a good idea, but I
> actually like the option of having coroutine-gthread because it's much
> friendlier to debug - gdb supports threads, but not coroutines.
> 
> Is coroutine-gthread blocking anything or is it just that you're not
> entirely confident in its correctness?

I'm not entirely confident in its correctness, and I'd be afraid of
breaking things when converting dataplane to AIOContext.

Paolo

Re: [Qemu-devel] getting rid of coroutine-gthread?

[Kevin Wolf]

Am 15.01.2013 14:28, schrieb Paolo Bonzini:
> Il 15/01/2013 14:18, Kevin Wolf ha scritto:
>>>> Brad and Peter,
>>>>
>>>> as far as I know OpenBSD and Linux/ARM were the main users of
>>>> coroutine-gthread.  Do you think we could dump it and rely on
>>>> coroutine-sigaltstack only?  The differences in signal handling of the
>>>> gthread implementation always worried me.
>>>>
>>>> What versions of OpenBSD would we have to drop support for?  Is that
>>>> acceptable to you?
>> Changing the defaults for these platforms may be a good idea, but I
>> actually like the option of having coroutine-gthread because it's much
>> friendlier to debug - gdb supports threads, but not coroutines.
>>
>> Is coroutine-gthread blocking anything or is it just that you're not
>> entirely confident in its correctness?
> 
> I'm not entirely confident in its correctness, and I'd be afraid of
> breaking things when converting dataplane to AIOContext.

Dataplane is (at least for now) not the most important thing to have
when debugging a block driver. Would it help if we made dataplane and
coroutine-gthread mutually exclusive?

Kevin

Re: [Qemu-devel] getting rid of coroutine-gthread?

[Paolo Bonzini]

Il 15/01/2013 14:40, Kevin Wolf ha scritto:
>> > I'm not entirely confident in its correctness, and I'd be afraid of
>> > breaking things when converting dataplane to AIOContext.
> Dataplane is (at least for now) not the most important thing to have
> when debugging a block driver. Would it help if we made dataplane and
> coroutine-gthread mutually exclusive?

I thought the plan was to make dataplane the default.  Anyway no
problem, we'll see.

Paolo