Re: [boost] [Fibers] Performance

Subject: Re: [boost] [Fibers] Performance
From: Oliver Kowalke (oliver.kowalke_at_[hidden])
Date: 2014-01-20 02:07:22

2014/1/19 Gavin Lambert <gavinl_at_[hidden]>

> I asked that because Oliver seems to me to be focusing many of his replies
> in this thread and elsewhere to "it makes Asio syntax cleaner", which I
> don't feel is a sufficient justification for this library to exist by
> itself, because Coroutine already does that.
>

correct - but think on the one-thread-per-clientpattern (which most
developers are familiar with) which is easy to write and understand than
using callbacks - both using asnyc I/O.
one-thread-per-client -> one-fiber-per-client
with coroutines you can't use the one-fiber-per-client because you are
missing the synchronization classes.

> If you are running on a single thread, you do not require any locks at all
> on the queue, and barely any kind of synchronisation to have consumers go
> to sleep when idle and be woken up when new work arrives.
>

hmm - the library doesn't uses locks in the sense of thread-locks

fibers are a thin wrapper around coroutines and you are able to do
something like:

void fn1() {};
fiber f1(fn1);

void fn2() { f1.join(); }
fiber f2( fn2);

e.g. a fiber can join another fiber as you know it from threads (coroutines
do not provide this feature or you would have to implement it as
boost.fiber already tries to provide).

>
> Although granted this library would theoretically make life easier than
> the alternatives if the consumers also needed to sleep on things other than
> the queue itself -- though again, if you're running in one thread you don't
> need locks, so there's not much you need to sleep on.
>

fiber does not sleep - they are suspended (its stack and registers are
preserved) and if the condition for which the fiber was suspended becomes
true it will be resumed, e.g. the registers are restored in the cpu and
the stackpoint is restored too. so it is not real locking as threads but
the fiber library provides classes as std::thread API (but the internal
implementation and the used mechanisms are different).

> It's only really when you go to M:N that something like this becomes
> especially valuable.
>

not realy even if you do cooperative scheduling == userland-threads (which
can run concurrently in one thread) you need classes for coordinating the
fibers
_______________________________________________