On 05/25/2011 12:09 AM, Stefan Hajnoczi wrote:
> On Tue, May 24, 2011 at 9:51 PM, Jamie Lokier wrote:
>> Stefan Hajnoczi wrote:
>>> My current plan is to try using sigaltstack(2) instead of
>>> makecontext()/swapcontext() as a hack since OpenBSD doesn't have
>>> makecontext()/swapcontext().
>>
>>
On Tue, May 24, 2011 at 9:51 PM, Jamie Lokier wrote:
> Stefan Hajnoczi wrote:
>> My current plan is to try using sigaltstack(2) instead of
>> makecontext()/swapcontext() as a hack since OpenBSD doesn't have
>> makecontext()/swapcontext().
>
> sigaltstack() is just a system call to tell the system
On 05/24/2011 11:21 PM, Anthony Liguori wrote:
Why not use threads as a coroutine fallback? That's essentially what we
would do to be "fully threaded".
Not exactly, there would be much less synchronization going on. Using
threads to implement coroutines means you go through the slow path of
Le mardi 24 mai 2011 21:58:12, Stefan Hajnoczi a écrit :
> On Tue, May 24, 2011 at 08:37:50PM +0100, Jamie Lokier wrote:
> TBH I'm almost at the stage where I think we should just use threads
> and/or async callbacks, as appropriate. Hopefully I'll be able to cook
> up a reasonably portable implem
On 05/24/2011 02:58 PM, Stefan Hajnoczi wrote:
On Tue, May 24, 2011 at 08:37:50PM +0100, Jamie Lokier wrote:
Daniel P. Berrange wrote:
On Wed, May 11, 2011 at 03:45:39PM +0200, Paolo Bonzini wrote:
On 05/11/2011 03:05 PM, Anthony Liguori wrote:
A very slow way, too (on Windows at least if yo
On 05/24/2011 02:58 PM, Stefan Hajnoczi wrote:
On Tue, May 24, 2011 at 08:37:50PM +0100, Jamie Lokier wrote:
Thanks, I read about that but didn't try to implement special cases
because I don't have relevant OSes here to test against.
My current plan is to try using sigaltstack(2) instead of
make
Stefan Hajnoczi wrote:
> My current plan is to try using sigaltstack(2) instead of
> makecontext()/swapcontext() as a hack since OpenBSD doesn't have
> makecontext()/swapcontext().
sigaltstack() is just a system call to tell the system about an
alternative signal stack - that you have allocated yo
On Tue, May 24, 2011 at 08:37:50PM +0100, Jamie Lokier wrote:
> Daniel P. Berrange wrote:
> > On Wed, May 11, 2011 at 03:45:39PM +0200, Paolo Bonzini wrote:
> > > On 05/11/2011 03:05 PM, Anthony Liguori wrote:
> > > >>
> > > >>A very slow way, too (on Windows at least if you use qemu_cond...).
> >
Stefan Hajnoczi wrote:
> On Thu, May 12, 2011 at 10:51 AM, Jan Kiszka wrote:
> > On 2011-05-11 12:15, Stefan Hajnoczi wrote:
> >> From: Kevin Wolf
> >>
> >> Asynchronous code is becoming very complex. At the same time
> >> synchronous code is growing because it is convenient to write.
> >> Somet
Daniel P. Berrange wrote:
> On Wed, May 11, 2011 at 03:45:39PM +0200, Paolo Bonzini wrote:
> > On 05/11/2011 03:05 PM, Anthony Liguori wrote:
> > >>
> > >>A very slow way, too (on Windows at least if you use qemu_cond...).
> > >
> > >That doesn't mean you can't do a fiber implementation for Windows
Am 12.05.2011 11:51, schrieb Jan Kiszka:
> On 2011-05-11 12:15, Stefan Hajnoczi wrote:
>> From: Kevin Wolf
>>
>> Asynchronous code is becoming very complex. At the same time
>> synchronous code is growing because it is convenient to write.
>> Sometimes duplicate code paths are even added, one syn
On Thu, May 12, 2011 at 10:51 AM, Jan Kiszka wrote:
> On 2011-05-11 12:15, Stefan Hajnoczi wrote:
>> From: Kevin Wolf
>>
>> Asynchronous code is becoming very complex. At the same time
>> synchronous code is growing because it is convenient to write.
>> Sometimes duplicate code paths are even ad
On 2011-05-11 12:15, Stefan Hajnoczi wrote:
> From: Kevin Wolf
>
> Asynchronous code is becoming very complex. At the same time
> synchronous code is growing because it is convenient to write.
> Sometimes duplicate code paths are even added, one synchronous and the
> other asynchronous. This pa
Am 11.05.2011 21:12, schrieb Stefan Weil:
> Am 11.05.2011 12:15, schrieb Stefan Hajnoczi:
>> From: Kevin Wolf
>>
>> Asynchronous code is becoming very complex. At the same time
>> synchronous code is growing because it is convenient to write.
>> Sometimes duplicate code paths are even added, one s
Am 11.05.2011 12:15, schrieb Stefan Hajnoczi:
From: Kevin Wolf
Asynchronous code is becoming very complex. At the same time
synchronous code is growing because it is convenient to write.
Sometimes duplicate code paths are even added, one synchronous and the
other asynchronous. This patch introd
On Wed, May 11, 2011 at 03:45:39PM +0200, Paolo Bonzini wrote:
> On 05/11/2011 03:05 PM, Anthony Liguori wrote:
> >>
> >>A very slow way, too (on Windows at least if you use qemu_cond...).
> >
> >That doesn't mean you can't do a fiber implementation for Windows... but
> >having a highly portable fa
On 05/11/2011 03:05 PM, Anthony Liguori wrote:
A very slow way, too (on Windows at least if you use qemu_cond...).
That doesn't mean you can't do a fiber implementation for Windows... but
having a highly portable fallback is a good thing.
I agree but where would you place it, since QEMU is o
On 05/11/2011 07:52 AM, Paolo Bonzini wrote:
On 05/11/2011 02:51 PM, Anthony Liguori wrote:
How about a generic thread fallback? That's what we do in gtk-vnc and
it solves the portability issue in a very robust way.
A very slow way, too (on Windows at least if you use qemu_cond...).
That doe
Am 11.05.2011 14:36, schrieb Anthony Liguori:
> On 05/11/2011 05:15 AM, Stefan Hajnoczi wrote:
>> From: Kevin Wolf
>>
>> Asynchronous code is becoming very complex. At the same time
>> synchronous code is growing because it is convenient to write.
>> Sometimes duplicate code paths are even added,
On Wed, May 11, 2011 at 1:46 PM, Paolo Bonzini wrote:
> On 05/11/2011 02:36 PM, Anthony Liguori wrote:
> diff --git a/coroutine-win32.c b/coroutine-win32.c
Kevin: This reminds me that I did not run ./check-coroutine on win32.
If you are able to run it in your environment that would be good to
mak
On 05/11/2011 02:51 PM, Anthony Liguori wrote:
How about a generic thread fallback? That's what we do in gtk-vnc and
it solves the portability issue in a very robust way.
A very slow way, too (on Windows at least if you use qemu_cond...).
Paolo
On 05/11/2011 07:04 AM, Paolo Bonzini wrote:
On 05/11/2011 12:15 PM, Stefan Hajnoczi wrote:
+#ifdef __i386__
+ asm volatile(
+ "mov %%esp, %%ebx;"
+ "mov %0, %%esp;"
+ "pushl %1;"
+ "call _trampoline;"
+ "mov %%ebx, %%esp;"
+ : : "r" (co->stack + co->stack_size), "r" (co) : "ebx"
+ );
This is
On 05/11/2011 02:36 PM, Anthony Liguori wrote:
So the only Linux host we support is x86??
We can't reasonably do this IMHO. If we're going to go this route, we
should at least fall back to setcontext for the sake of portability.
That was:
diff --git a/coroutine-win32.c b/coroutine-win32.c
n
On 05/11/2011 05:15 AM, Stefan Hajnoczi wrote:
From: Kevin Wolf
Asynchronous code is becoming very complex. At the same time
synchronous code is growing because it is convenient to write.
Sometimes duplicate code paths are even added, one synchronous and the
other asynchronous. This patch intr
Am 11.05.2011 14:04, schrieb Paolo Bonzini:
> On 05/11/2011 12:15 PM, Stefan Hajnoczi wrote:
>> +#ifdef __i386__
>> +asm volatile(
>> +"mov %%esp, %%ebx;"
>> +"mov %0, %%esp;"
>> +"pushl %1;"
>> +"call _trampoline;"
>> +"mov %%ebx, %%esp;"
>> +: :
On 05/11/2011 12:15 PM, Stefan Hajnoczi wrote:
+#ifdef __i386__
+asm volatile(
+"mov %%esp, %%ebx;"
+"mov %0, %%esp;"
+"pushl %1;"
+"call _trampoline;"
+"mov %%ebx, %%esp;"
+: : "r" (co->stack + co->stack_size), "r" (co) : "ebx"
+);
This i
Am 11.05.2011 12:15, schrieb Stefan Hajnoczi:
> From: Kevin Wolf
>
> Asynchronous code is becoming very complex. At the same time
> synchronous code is growing because it is convenient to write.
> Sometimes duplicate code paths are even added, one synchronous and the
> other asynchronous. This
From: Kevin Wolf
Asynchronous code is becoming very complex. At the same time
synchronous code is growing because it is convenient to write.
Sometimes duplicate code paths are even added, one synchronous and the
other asynchronous. This patch introduces coroutines which allow code
that looks sy
28 matches
Mail list logo
