2014/1/19 Gavin Lambert
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 _______________________________________________