Boost logo

Boost :

Subject: Re: [boost] new libaray Boost.Fiber in vault
From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2008-11-01 16:14:29


> Am Samstag, 1. November 2008 19:24:30 schrieb Hartmut Kaiser:
> > > Am Samstag, 1. November 2008 14:43:53 schrieb Mathias Gaunard:
> > > > k-oli_at_[hidden] wrote:
> > > > > I've added Boost.Fiber to the boost vault.
> > > > > The library implements lightweight threads of execution
> (context
> > > > > swapping; fibers on Windows).
> > > >
> > > > Are you aware that there is already a library in the work that
> does
> > > > this, Boost.Coroutine?
> > >
> > > Yes but it doesn't compile on my systems.
> >
> > I'm using it in mission critical code and it works just fine.
>
> I tried Linux amd64 - doesn't compile :(

Well, the linux amd64 code in the SVN is an early version of the code I
wrote. Seems I need to commit my current stuff to SVN. Sorry for not keeping
it up to date. Give me some time to sort things out here.

> > > I need a Fiber library for the threadpool library.
> > > Coroutines are a form of control flow and fibers are a systems-
> level
> > > construct.
> >
> > The Coroutines library is built on top of a context switching/fibers
> > component supporting better/faster context switching than yours (at
> least
> > on gcc based platforms), currently.
>
> Could you please explain why it is faster? I'm
> using ::makecontext()/::CreateFiber() too.

On windows you can't make it faster than using native fibers, indeed. I
tried using assembly here but this opens another can of worms as it
interferes with certain (undocumented) assumptions the OS is making.

OTOH, on gcc based platforms the Coroutines lib uses small assembly routines
for the context switching itself, which is way faster than makecontext
because this requires a kernel call.

My measurements show the assembly code being approx 10 times faster than
using native fibers. I didn't do any measurements comparing the makecontext
version, though.

Regards Hartmut


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk