Forthcoming Boost.Fiber review
Hi all, The review of Boost.Fiber by Oliver Kowalke is scheduled from Monday, January 6th to January 12th. ----------------------------------------------------- About the library: Boost.Fiber provides a framework for micro-/userland-threads (fibers) scheduled cooperatively. The API contains classes and functions to manage and synchronize fibers similar to Boost.Thread. Each fiber has its own stack. A fiber can save the current execution state, including all registers and CPU flags, the instruction pointer, and the stack pointer and later restore this state. The idea is to have multiple execution paths running on a single thread using a sort of cooperative scheduling (versus threads, which are preemptively scheduled). The running fiber decides explicitly when it should yield to allow another fiber to run (context switching). Boost.Fiberinternally uses coroutines from Boost.Coroutine <http://ok73.funpic.de/boost/libs/coroutine/index.html>; the classes in this library manage, schedule and, when needed, synchronize those coroutines. A context switch between threads usually costs thousands of CPU cycles on x86, compared to a fiber switch with a few hundred cycles. A fiber can only run on a single thread at any point in time. docs: http://ok73.funpic.de/boost/libs/fiber/doc/html/index.html<http://ok73.ok.funpic.de/boost/libs/coroutine/doc/html/> git: https://github.com/olk/boost-fiber src: http://ok73.ok.funpic.de/boost.fiber.zip<http://ok73.ok.funpic.de/boost.coroutine.zip> --------------------------------------------------- Naturally, you need not wait until the review formally opens to start reviewing the Fiber library. Please always state in your review whether you think the library should be accepted as a Boost library! Additionally please consider giving feedback on the following general topics: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Nat Goodspeed Boost.Fiber Review Manager ------------------------------
Hi! Docs link isn't working... -> 404 On 18 December 2013 20:03, Nat Goodspeed <nat@lindenlab.com> wrote:
Hi all,
The review of Boost.Fiber by Oliver Kowalke is scheduled from Monday, January 6th to January 12th.
----------------------------------------------------- About the library:
Boost.Fiber provides a framework for micro-/userland-threads (fibers) scheduled cooperatively. The API contains classes and functions to manage and synchronize fibers similar to Boost.Thread. Each fiber has its own stack.
A fiber can save the current execution state, including all registers and CPU flags, the instruction pointer, and the stack pointer and later restore this state. The idea is to have multiple execution paths running on a single thread using a sort of cooperative scheduling (versus threads, which are preemptively scheduled). The running fiber decides explicitly when it should yield to allow another fiber to run (context switching). Boost.Fiberinternally uses coroutines from Boost.Coroutine <http://ok73.funpic.de/boost/libs/coroutine/index.html>; the classes in this library manage, schedule and, when needed, synchronize those coroutines. A context switch between threads usually costs thousands of CPU cycles on x86, compared to a fiber switch with a few hundred cycles. A fiber can only run on a single thread at any point in time.
docs: http://ok73.funpic.de/boost/libs/fiber/doc/html/index.html<http://ok73.ok.funpic.de/boost/libs/coroutine/doc/html/> git: https://github.com/olk/boost-fiber src: http://ok73.ok.funpic.de/boost.fiber.zip<http://ok73.ok.funpic.de/boost.coroutine.zip>
---------------------------------------------------
Naturally, you need not wait until the review formally opens to start reviewing the Fiber library. Please always state in your review whether you think the library should be accepted as a Boost library!
Additionally please consider giving feedback on the following general topics:
- What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Nat Goodspeed Boost.Fiber Review Manager ------------------------------
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
-- Carlos Miguel Ferreira Researcher at Telecommunications Institute Aveiro - Portugal Work E-mail - cmf@av.it.pt Skype & GTalk -> carlosmf.pt@gmail.com LinkedIn -> http://www.linkedin.com/in/carlosmferreira
2013/12/18 Carlos Ferreira <carlosmf.pt@gmail.com>
Hi! Docs link isn't working... -> 404
copy-&-paste, sorry :/ - it should be http://ok73.ok.funpic.de/boost/libs/fiber/doc/html/
2013/12/18 Oliver Kowalke <oliver.kowalke@gmail.com>
2013/12/18 Carlos Ferreira <carlosmf.pt@gmail.com>
Hi! Docs link isn't working... -> 404
docs: http://ok73.ok.funpic.de/boost/libs/fiber/doc/html/ src: http://ok73.ok.funpic.de/boost.fiber.zip
Maybe you are not aware of this. From the documentation link that you provided, there is advertisement popup in every page. -- View this message in context: http://boost.2283326.n4.nabble.com/Forthcoming-Boost-Fiber-review-tp4656727p... Sent from the Boost - Users mailing list archive at Nabble.com.
Nat, one question. How stable is the lib? Boost.Fiber seems to be exactly what I need, but I would prefer to use a stable version. Can you give me information regarding that aspect? Thanks! :) On 18 December 2013 22:27, kwanti <ngkwanti@gmail.com> wrote:
Maybe you are not aware of this. From the documentation link that you provided, there is advertisement popup in every page.
-- View this message in context: http://boost.2283326.n4.nabble.com/Forthcoming-Boost-Fiber-review-tp4656727p... Sent from the Boost - Users mailing list archive at Nabble.com. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
-- Carlos Miguel Ferreira Researcher at Telecommunications Institute Aveiro - Portugal Work E-mail - cmf@av.it.pt Skype & GTalk -> carlosmf.pt@gmail.com LinkedIn -> http://www.linkedin.com/in/carlosmferreira
On Wed, Dec 18, 2013 at 6:03 PM, Carlos Ferreira <carlosmf.pt@gmail.com>wrote: Nat, one question.
How stable is the lib?
Boost.Fiber seems to be exactly what I need, but I would prefer to use a stable version. Can you give me information regarding that aspect? Thanks! :)
It's exactly what I need too. Undergoing the Boost review process and becoming officially part of the Boost libraries makes it that much more stable. Oliver has extensive self-testing. I know that he has run his tests and examples on Windows, Mac and Linux, 32-bit and 64-bit, with a few different gcc versions. I have successfully dropped it into (a fork of) a large production program, replacing an older, less official library with similar functionality. On that basis, I'm comfortable that it's ready for a broader review. But it's really the review itself that allows us to call a library "stable." You might mean: is the API still changing? or: how buggy is it, on my platform, for my use case? The Boost review process invites many people, on many platforms, with many use cases, to consider the API and hopefully to test the library for themselves. The intention is to flush out desired/required API changes, as well as obscure bugs. It is often the case that a library author is requested to refine the API and then to resubmit for a shorter review cycle. Once the Boost community reaches consensus, then we can use the word "stable" with more confidence. Since you say you have a use case, if you would be so good as to try the library yourself and submit a review, you will help it to reach "stable" status.
Well, the reason why I asked about that, was because my use-case is an Openflow Controller which needs to support a massive number of open sockets. This use case needs to be stable enough for demonstration and prototype purposes. You are right! I should have asked instead "Will the API change" which is probably a much better question for this use-case. Unfortunately I don't have much time to spend in reviews nor I can give myself to the luxury of waiting for new code submissions, in order to solve a certain problem. For now, I will stick to the normal Boost.Coroutines (despite I also have a few problems with that. Please watch my next post for further detail). If I really need the capabilities that the Fiber framework is providing, then I will surely contribute. Thanks for your (and the other developers) work. On 19 December 2013 02:01, Nat Goodspeed <nat@lindenlab.com> wrote:
On Wed, Dec 18, 2013 at 6:03 PM, Carlos Ferreira <carlosmf.pt@gmail.com>wrote:
Nat, one question.
How stable is the lib?
Boost.Fiber seems to be exactly what I need, but I would prefer to use a stable version. Can you give me information regarding that aspect? Thanks! :)
It's exactly what I need too. Undergoing the Boost review process and becoming officially part of the Boost libraries makes it that much more stable.
Oliver has extensive self-testing. I know that he has run his tests and examples on Windows, Mac and Linux, 32-bit and 64-bit, with a few different gcc versions. I have successfully dropped it into (a fork of) a large production program, replacing an older, less official library with similar functionality. On that basis, I'm comfortable that it's ready for a broader review.
But it's really the review itself that allows us to call a library "stable." You might mean: is the API still changing? or: how buggy is it, on my platform, for my use case? The Boost review process invites many people, on many platforms, with many use cases, to consider the API and hopefully to test the library for themselves. The intention is to flush out desired/required API changes, as well as obscure bugs. It is often the case that a library author is requested to refine the API and then to resubmit for a shorter review cycle.
Once the Boost community reaches consensus, then we can use the word "stable" with more confidence.
Since you say you have a use case, if you would be so good as to try the library yourself and submit a review, you will help it to reach "stable" status.
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
-- Carlos Miguel Ferreira Researcher at Telecommunications Institute Aveiro - Portugal Work E-mail - cmf@av.it.pt Skype & GTalk -> carlosmf.pt@gmail.com LinkedIn -> http://www.linkedin.com/in/carlosmferreira
On Thu, Dec 19, 2013 at 5:44 AM, Carlos Ferreira <carlosmf.pt@gmail.com>wrote: Well, the reason why I asked about that, was because my use-case is an
Openflow Controller which needs to support a massive number of open sockets.
Oliver will tell you that such a use case is a good fit.
This use case needs to be stable enough for demonstration and prototype purposes. You are right! I should have asked instead "Will the API change" which is probably a much better question for this use-case.
I can tell you it won't change immediately. What's out there now is Oliver's proposed API. The review won't even start until January 6, and it runs until January 15 (update from announcement mail, btw). The Review Manager (ahem) will try to organize review feedback into a coherent set of recommendations for the library author. That feedback might be: thumbs up! Ship it! Or it might involve API changes. Oliver will then respond to those recommendations.
For now, I will stick to the normal Boost.Coroutines (despite I also have a few problems with that. Please watch my next post for further detail). If I really need the capabilities that the Fiber framework is providing, then I will surely contribute.
Thank you, and good luck.
On 19/12/2013 11:27, Quoth kwanti:
Maybe you are not aware of this. From the documentation link that you provided, there is advertisement popup in every page.
It's a particularly offensive one in that it has supposed "close" buttons that actually open a popup window. But this library sounds interesting. When it was initially mentioned I was wondering how it related to Coroutine, since they sound like similar problem domains. But now I see that it uses Coroutine as a basis. One very minor quibble (which I'll share now because I'm not sure if I'll be around during the formal review period): I don't like how the library is called "Fiber", in subdir "fiber", but in namespace "fibers". I do prefer namespace "fibers" (since boost::fiber::fiber would be annoying), but I think the library and dir should also be called "fibers" too. On the other hand, the singular is more consistent with other Boost library names and with Thread, which it is intended to resemble (though that avoids the namespace issue by putting everything directly into "boost"). As I said, just a minor quibble. Feel free to -1 it. :)
One very minor quibble (which I'll share now because I'm not sure if I'll be around during the formal review period): I don't like how the library is called "Fiber", in subdir "fiber", but in namespace "fibers". I do prefer namespace "fibers" (since boost::fiber::fiber would be annoying), but I think the library and dir should also be called "fibers" too.
There is precedent for this pattern in Boost: Boost.Coroutine places its names in boost::coroutines Boost.Tuple places its names in boost::tuples There are probably others that don't come to mind at the moment. Regards, Nate
On Wed, Dec 18, 2013 at 9:29 PM, Gavin Lambert <gavinl@compacsort.com>wrote: this library sounds interesting. When it was initially mentioned I was
wondering how it related to Coroutine, since they sound like similar problem domains. But now I see that it uses Coroutine as a basis.
It's an important point, one that I had to absorb myself. The Google Summer of Code 2006 "Boost.Coroutine" project conflates the two ideas. Oliver teases them apart. You construct coroutines when you want them freely and frequently passing control back and forth. Perhaps you're constructing a pipeline of potentially-stateful filters, where you want to use control flow as well as local data to govern the subsequent behavior of a given filter. Control transfer with a coroutine is immediate: when you ask an upstream coroutine for a value, you suspend until it delivers that one value. Similar remarks when you pass a value to a downstream coroutine. It's like an ordinary function call: the calling function immediately suspends until the called function returns. Fibers are much more analogous to threads, in that launching a fiber gives it a more-or-less independent run. You *may* choose to synchronize two fibers, but you need not. When you coordinate with another fiber using (e.g.) future and promise, setting the value in the promise does not immediately suspend the calling fiber. It only marks the waiting fiber ready to run. Fibers are useful when, for instance, you must make a sequence of asynchronous network requests. Of course you could also structure that code as a sequence of callbacks -- but quick, what's the control flow among those callbacks? Is there conditional behavior? How about looping? With a fiber, you can write what *appear* to be blocking calls, and wrap them in normal C++ control structures. Fibers are cheaper than threads. Better still (at least to me) is the implicit promise of cooperative scheduling. You cannot safely run legacy code (with potential references to global or static variables) on a new thread. You must first visit every code path, defending every such variable with appropriate thread synchronization. But on a given thread, at any given moment, you are guaranteed that only one fiber is running. One fiber will not interrupt another in an unpredictable state. Hope that helps...
2013/12/18 kwanti <ngkwanti@gmail.com>
Maybe you are not aware of this. From the documentation link that you provided, there is advertisement popup in every page.
It's a free page and I didn't noticed that they add advertisement popups because I'm using 'Adblock'. The html pages(documentation) is included in the zip-archive too, maybe this is an option for you.
It's okay for me. I raised this up just in case you are not aware of this. -- View this message in context: http://boost.2283326.n4.nabble.com/Forthcoming-Boost-Fiber-review-tp4656727p... Sent from the Boost - Users mailing list archive at Nabble.com.
2013/12/18 Nat Goodspeed <nat@lindenlab.com>
Hi all,
The review of Boost.Fiber by Oliver Kowalke is scheduled from Monday, January 6th to January 12th.
----------------------------------------------------- About the library:
Boost.Fiber provides a framework for micro-/userland-threads (fibers) scheduled cooperatively. The API contains classes and functions to manage and synchronize fibers similar to Boost.Thread. Each fiber has its own stack.
A fiber can save the current execution state, including all registers and CPU flags, the instruction pointer, and the stack pointer and later restore this state. The idea is to have multiple execution paths running on a single thread using a sort of cooperative scheduling (versus threads, which are preemptively scheduled). The running fiber decides explicitly when it should yield to allow another fiber to run (context switching). Boost.Fiberinternally uses coroutines from Boost.Coroutine <http://ok73.funpic.de/boost/libs/coroutine/index.html>; the classes in this library manage, schedule and, when needed, synchronize those coroutines. A context switch between threads usually costs thousands of CPU cycles on x86, compared to a fiber switch with a few hundred cycles. A fiber can only run on a single thread at any point in time.
docs: http://ok73.funpic.de/boost/libs/fiber/doc/html/index.html<http://ok73.ok.funpic.de/boost/libs/coroutine/doc/html/> git: https://github.com/olk/boost-fiber src: http://ok73.ok.funpic.de/boost.fiber.zip<http://ok73.ok.funpic.de/boost.coroutine.zip>
---------------------------------------------------
Naturally, you need not wait until the review formally opens to start reviewing the Fiber library. Please always state in your review whether you think the library should be accepted as a Boost library!
Additionally please consider giving feedback on the following general topics:
- What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Nat Goodspeed Boost.Fiber Review Manager
the documentation is now available at http://olk.github.io/libs/fiber/doc/html/ too (no popup-windows)
Thanks for the doc! Is it possible to say when will the Fiber lib be givin the "ok!" to be used in a production environment? On 20 December 2013 15:19, Oliver Kowalke <oliver.kowalke@gmail.com> wrote:
2013/12/18 Nat Goodspeed <nat@lindenlab.com>
Hi all,
The review of Boost.Fiber by Oliver Kowalke is scheduled from Monday, January 6th to January 12th.
----------------------------------------------------- About the library:
Boost.Fiber provides a framework for micro-/userland-threads (fibers) scheduled cooperatively. The API contains classes and functions to manage and synchronize fibers similar to Boost.Thread. Each fiber has its own stack.
A fiber can save the current execution state, including all registers and CPU flags, the instruction pointer, and the stack pointer and later restore this state. The idea is to have multiple execution paths running on a single thread using a sort of cooperative scheduling (versus threads, which are preemptively scheduled). The running fiber decides explicitly when it should yield to allow another fiber to run (context switching). Boost.Fiberinternally uses coroutines from Boost.Coroutine <http://ok73.funpic.de/boost/libs/coroutine/index.html>; the classes in this library manage, schedule and, when needed, synchronize those coroutines. A context switch between threads usually costs thousands of CPU cycles on x86, compared to a fiber switch with a few hundred cycles. A fiber can only run on a single thread at any point in time.
docs: http://ok73.funpic.de/boost/libs/fiber/doc/html/index.html<http://ok73.ok.funpic.de/boost/libs/coroutine/doc/html/> git: https://github.com/olk/boost-fiber src: http://ok73.ok.funpic.de/boost.fiber.zip<http://ok73.ok.funpic.de/boost.coroutine.zip>
---------------------------------------------------
Naturally, you need not wait until the review formally opens to start reviewing the Fiber library. Please always state in your review whether you think the library should be accepted as a Boost library!
Additionally please consider giving feedback on the following general topics:
- What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Nat Goodspeed Boost.Fiber Review Manager
the documentation is now available at http://olk.github.io/libs/fiber/doc/html/ too (no popup-windows)
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
-- Carlos Miguel Ferreira Researcher at Telecommunications Institute Aveiro - Portugal Work E-mail - cmf@av.it.pt Skype & GTalk -> carlosmf.pt@gmail.com LinkedIn -> http://www.linkedin.com/in/carlosmferreira
On Mon, Jan 20, 2014 at 04:48:45PM +0000, Carlos Ferreira wrote:
Is it possible to say when will the Fiber lib be givin the "ok!" to be used in a production environment?
When the review manager has collected all the feedback and reviews, and made an informed decision on its acceptance, conditional acceptance or rejection from Boost. As for "production environment", the inclusion into Boost doesn't really guarantee any of that sort. It's up to you to judge if the problems raised during the review process are blocking enough for you to trust it in production. Some libraries that are rejected are still very usable in their proposed non-accepted form, while some libraries are accepted even if they are brittle and in need of some serious work to be "production-grade". In the end, it's a judgement you have to make off the reviews, the review-manager's summary and all the things that crop up once people start to try to use the library. As for absolute timeframes between reviews and resolution, anything from a few days from the review deadline to several weeks afterwards based on a sampling of earlier review results. This assumedly varies a lot based on the issues raised during review and the spread of reviews. -- Lars Viklund | zao@acc.umu.se
Hello again. Ok, now I'm sure Boost.Fiber is the only (simply) way I have to solve my problem. The project on which I'm working, requires a TCP session per client. Between the client and the server, it is possible that at some point in time, the client and the server will have to manage different contexts of conversations using the same TCP Session. I simply don't know how to do this in the old fashion way. Documentation regarding coroutines is scarce and the examples are too simplistic. What I know is that the Fiber Documentation provided by Oliver states that Boost.Coroutine does not provide a way to synchronize different coroutines execution. Anyway, it seems that I definitely have to use Oliver's Fiber lib. So now my problem is, how do I build this lib? How can I compile it and link it to the boost libs already installed in my computer? The readme.md file says to look at the docs in https://svn.boost.org/trac/boost/wiki/TryModBoost but that left me kinda lost... Thanks for any help! On 20 January 2014 17:33, Lars Viklund <zao@acc.umu.se> wrote:
On Mon, Jan 20, 2014 at 04:48:45PM +0000, Carlos Ferreira wrote:
Is it possible to say when will the Fiber lib be givin the "ok!" to be used in a production environment?
When the review manager has collected all the feedback and reviews, and made an informed decision on its acceptance, conditional acceptance or rejection from Boost.
As for "production environment", the inclusion into Boost doesn't really guarantee any of that sort. It's up to you to judge if the problems raised during the review process are blocking enough for you to trust it in production.
Some libraries that are rejected are still very usable in their proposed non-accepted form, while some libraries are accepted even if they are brittle and in need of some serious work to be "production-grade".
In the end, it's a judgement you have to make off the reviews, the review-manager's summary and all the things that crop up once people start to try to use the library.
As for absolute timeframes between reviews and resolution, anything from a few days from the review deadline to several weeks afterwards based on a sampling of earlier review results. This assumedly varies a lot based on the issues raised during review and the spread of reviews.
-- Lars Viklund | zao@acc.umu.se _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
-- Carlos Miguel Ferreira Researcher at Telecommunications Institute Aveiro - Portugal Work E-mail - cmf@av.it.pt Skype & GTalk -> carlosmf.pt@gmail.com LinkedIn -> http://www.linkedin.com/in/carlosmferreira
On Fri, Jan 24, 2014 at 6:51 PM, Carlos Ferreira <carlosmf.pt@gmail.com> wrote:
So now my problem is, how do I build this lib? How can I compile it and link it to the boost libs already installed in my computer? The readme.md file says to look at the docs in https://svn.boost.org/trac/boost/wiki/TryModBoost but that left me kinda lost...
Okay, if the new hotness leaves you cold, it's still possible to drop the Fiber library into an exploded Boost 1.55 tarball tree like this: 1. Drop the Fiber library into a Boost tree as libs/fiber. That is, under libs/fiber you should find build, examples, include, src, ... 2. Symlink boost/fiber -> ../libs/fiber/include/boost/fiber . If you must, you can physically move libs/fiber/include/boost/fiber to boost/fiber; but even Windows supports symlinks these days. 3. At this point, a normal ./b2 libs/fiber should suffice to build the Fiber library and everything on which it depends.
Hi again! I'm having some trouble using the boost lib, freshly cloned from the repo. I compiled the release version but when I configure my project to use the new includes and libs, the compiler throws several errors, most of them are boost/boost/asio/impl/spawn.hpp:263:77: error: no matching function for
call to ‘boost::coroutines::coroutine<void()>::coroutine(boost::coroutines::attributes&)’
When I use the system build (installed from Arch Linux repos), everything compiles smoothly without any problems. Does anyone knows what might be the problem? On 25 January 2014 01:24, Nat Goodspeed <nat@lindenlab.com> wrote:
On Fri, Jan 24, 2014 at 6:51 PM, Carlos Ferreira <carlosmf.pt@gmail.com> wrote:
So now my problem is, how do I build this lib? How can I compile it and link it to the boost libs already installed in my computer? The readme.mdfile says to look at the docs in https://svn.boost.org/trac/boost/wiki/TryModBoost but that left me kinda lost...
Okay, if the new hotness leaves you cold, it's still possible to drop the Fiber library into an exploded Boost 1.55 tarball tree like this:
1. Drop the Fiber library into a Boost tree as libs/fiber. That is, under libs/fiber you should find build, examples, include, src, ... 2. Symlink boost/fiber -> ../libs/fiber/include/boost/fiber . If you must, you can physically move libs/fiber/include/boost/fiber to boost/fiber; but even Windows supports symlinks these days. 3. At this point, a normal ./b2 libs/fiber should suffice to build the Fiber library and everything on which it depends. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
-- Carlos Miguel Ferreira Researcher at Telecommunications Institute Aveiro - Portugal Work E-mail - cmf@av.it.pt Skype & GTalk -> carlosmf.pt@gmail.com LinkedIn -> http://www.linkedin.com/in/carlosmferreira
2014-01-27 Carlos Ferreira <carlosmf.pt@gmail.com>
boost/boost/asio/impl/spawn.hpp:263:77: error: no matching function for
call to ‘boost::coroutines::coroutine<void()>::coroutine(boost::coroutines::attributes&)’
this comes from boost.asio and 'coroutine<void()>' is the old coroutine interface (deprecated)
Well this is a bit strange because the arch linux boost version is the 1.55 and the git clone that I got from the git boost repo, is also the 1.55 Why is one version working and the other isn't ? On 27 January 2014 13:34, Oliver Kowalke <oliver.kowalke@gmail.com> wrote:
2014-01-27 Carlos Ferreira <carlosmf.pt@gmail.com>
boost/boost/asio/impl/spawn.hpp:263:77: error: no matching function for
call to ‘boost::coroutines::coroutine<void()>::coroutine(boost::coroutines::attributes&)’
this comes from boost.asio and 'coroutine<void()>' is the old coroutine interface (deprecated)
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
-- Carlos Miguel Ferreira Researcher at Telecommunications Institute Aveiro - Portugal Work E-mail - cmf@av.it.pt Skype & GTalk -> carlosmf.pt@gmail.com LinkedIn -> http://www.linkedin.com/in/carlosmferreira
Ok, this may also help. include/boost/asio/spawn.hpp:90:7: error: ‘caller_type’ has not been
declared include/boost/asio/spawn.hpp:128:3: error: ‘caller_type’ does not name a type include/boost/asio/spawn.hpp:92:7: error: class ‘boost::asio::basic_yield_context<Handler>’ does not have any field named ‘ca_’
On 27 January 2014 13:43, Carlos Ferreira <carlosmf.pt@gmail.com> wrote:
Well this is a bit strange because the arch linux boost version is the 1.55 and the git clone that I got from the git boost repo, is also the 1.55
Why is one version working and the other isn't ?
On 27 January 2014 13:34, Oliver Kowalke <oliver.kowalke@gmail.com> wrote:
2014-01-27 Carlos Ferreira <carlosmf.pt@gmail.com>
boost/boost/asio/impl/spawn.hpp:263:77: error: no matching function for
call to ‘boost::coroutines::coroutine<void()>::coroutine(boost::coroutines::attributes&)’
this comes from boost.asio and 'coroutine<void()>' is the old coroutine interface (deprecated)
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
--
Carlos Miguel Ferreira Researcher at Telecommunications Institute Aveiro - Portugal Work E-mail - cmf@av.it.pt Skype & GTalk -> carlosmf.pt@gmail.com LinkedIn -> http://www.linkedin.com/in/carlosmferreira
-- Carlos Miguel Ferreira Researcher at Telecommunications Institute Aveiro - Portugal Work E-mail - cmf@av.it.pt Skype & GTalk -> carlosmf.pt@gmail.com LinkedIn -> http://www.linkedin.com/in/carlosmferreira
Never mind... I was including the spawn.hpp from asio which was breaking everything... Still, I don't know why it was compiling without problems, with the Arch-linux boost... On 27 January 2014 15:52, Carlos Ferreira <carlosmf.pt@gmail.com> wrote:
Ok, this may also help.
include/boost/asio/spawn.hpp:90:7: error: ‘caller_type’ has not been
declared include/boost/asio/spawn.hpp:128:3: error: ‘caller_type’ does not name a type include/boost/asio/spawn.hpp:92:7: error: class ‘boost::asio::basic_yield_context<Handler>’ does not have any field named ‘ca_’
On 27 January 2014 13:43, Carlos Ferreira <carlosmf.pt@gmail.com> wrote:
Well this is a bit strange because the arch linux boost version is the 1.55 and the git clone that I got from the git boost repo, is also the 1.55
Why is one version working and the other isn't ?
On 27 January 2014 13:34, Oliver Kowalke <oliver.kowalke@gmail.com>wrote:
2014-01-27 Carlos Ferreira <carlosmf.pt@gmail.com>
boost/boost/asio/impl/spawn.hpp:263:77: error: no matching function for
call to ‘boost::coroutines::coroutine<void()>::coroutine(boost::coroutines::attributes&)’
this comes from boost.asio and 'coroutine<void()>' is the old coroutine interface (deprecated)
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
--
Carlos Miguel Ferreira Researcher at Telecommunications Institute Aveiro - Portugal Work E-mail - cmf@av.it.pt Skype & GTalk -> carlosmf.pt@gmail.com LinkedIn -> http://www.linkedin.com/in/carlosmferreira
--
Carlos Miguel Ferreira Researcher at Telecommunications Institute Aveiro - Portugal Work E-mail - cmf@av.it.pt Skype & GTalk -> carlosmf.pt@gmail.com LinkedIn -> http://www.linkedin.com/in/carlosmferreira
-- Carlos Miguel Ferreira Researcher at Telecommunications Institute Aveiro - Portugal Work E-mail - cmf@av.it.pt Skype & GTalk -> carlosmf.pt@gmail.com LinkedIn -> http://www.linkedin.com/in/carlosmferreira
Hello Again This time, I'm having a weird problem, when setting the scheduler. If I have this
boost::asio::io_service &ioService(std::get<0>(*ioService_sPtr)); boost::fibers::asio::round_robin ds(ioService); boost::fibers::set_scheduling_algorithm(&ds); boost::asio::io_service::work workLine(ioService); ioService.run();
where ioService_sPtr is a pointer to a ioService already instantiated, the ioService.run() will return when the first yield returns the coroutine, ending the thread execution. If I don't set a scheduling algorithm, the run() will work properly, waiting for a job to execute or until stop() is called. Is this a normal behaviour? Thank you! On 27 January 2014 16:02, Carlos Ferreira <carlosmf.pt@gmail.com> wrote:
Never mind... I was including the spawn.hpp from asio which was breaking everything... Still, I don't know why it was compiling without problems, with the Arch-linux boost...
On 27 January 2014 15:52, Carlos Ferreira <carlosmf.pt@gmail.com> wrote:
Ok, this may also help.
include/boost/asio/spawn.hpp:90:7: error: ‘caller_type’ has not been
declared include/boost/asio/spawn.hpp:128:3: error: ‘caller_type’ does not name a type include/boost/asio/spawn.hpp:92:7: error: class ‘boost::asio::basic_yield_context<Handler>’ does not have any field named ‘ca_’
On 27 January 2014 13:43, Carlos Ferreira <carlosmf.pt@gmail.com> wrote:
Well this is a bit strange because the arch linux boost version is the 1.55 and the git clone that I got from the git boost repo, is also the 1.55
Why is one version working and the other isn't ?
On 27 January 2014 13:34, Oliver Kowalke <oliver.kowalke@gmail.com>wrote:
2014-01-27 Carlos Ferreira <carlosmf.pt@gmail.com>
boost/boost/asio/impl/spawn.hpp:263:77: error: no matching function
for call to ‘boost::coroutines::coroutine<void()>::coroutine(boost::coroutines::attributes&)’
this comes from boost.asio and 'coroutine<void()>' is the old coroutine interface (deprecated)
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
--
Carlos Miguel Ferreira Researcher at Telecommunications Institute Aveiro - Portugal Work E-mail - cmf@av.it.pt Skype & GTalk -> carlosmf.pt@gmail.com LinkedIn -> http://www.linkedin.com/in/carlosmferreira
--
Carlos Miguel Ferreira Researcher at Telecommunications Institute Aveiro - Portugal Work E-mail - cmf@av.it.pt Skype & GTalk -> carlosmf.pt@gmail.com LinkedIn -> http://www.linkedin.com/in/carlosmferreira
--
Carlos Miguel Ferreira Researcher at Telecommunications Institute Aveiro - Portugal Work E-mail - cmf@av.it.pt Skype & GTalk -> carlosmf.pt@gmail.com LinkedIn -> http://www.linkedin.com/in/carlosmferreira
-- Carlos Miguel Ferreira Researcher at Telecommunications Institute Aveiro - Portugal Work E-mail - cmf@av.it.pt Skype & GTalk -> carlosmf.pt@gmail.com LinkedIn -> http://www.linkedin.com/in/carlosmferreira
Nevermind that last e-mail... problem solved... On 28 January 2014 01:59, Carlos Ferreira <carlosmf.pt@gmail.com> wrote:
Hello Again
This time, I'm having a weird problem, when setting the scheduler.
If I have this
boost::asio::io_service &ioService(std::get<0>(*ioService_sPtr)); boost::fibers::asio::round_robin ds(ioService); boost::fibers::set_scheduling_algorithm(&ds); boost::asio::io_service::work workLine(ioService); ioService.run();
where ioService_sPtr is a pointer to a ioService already instantiated, the ioService.run() will return when the first yield returns the coroutine, ending the thread execution. If I don't set a scheduling algorithm, the run() will work properly, waiting for a job to execute or until stop() is called.
Is this a normal behaviour? Thank you!
On 27 January 2014 16:02, Carlos Ferreira <carlosmf.pt@gmail.com> wrote:
Never mind... I was including the spawn.hpp from asio which was breaking everything... Still, I don't know why it was compiling without problems, with the Arch-linux boost...
On 27 January 2014 15:52, Carlos Ferreira <carlosmf.pt@gmail.com> wrote:
Ok, this may also help.
include/boost/asio/spawn.hpp:90:7: error: 'caller_type' has not been
declared include/boost/asio/spawn.hpp:128:3: error: 'caller_type' does not name a type include/boost/asio/spawn.hpp:92:7: error: class 'boost::asio::basic_yield_context<Handler>' does not have any field named 'ca_'
On 27 January 2014 13:43, Carlos Ferreira <carlosmf.pt@gmail.com> wrote:
Well this is a bit strange because the arch linux boost version is the 1.55 and the git clone that I got from the git boost repo, is also the 1.55
Why is one version working and the other isn't ?
On 27 January 2014 13:34, Oliver Kowalke <oliver.kowalke@gmail.com>wrote:
2014-01-27 Carlos Ferreira <carlosmf.pt@gmail.com>
boost/boost/asio/impl/spawn.hpp:263:77: error: no matching function > for call to > 'boost::coroutines::coroutine<void()>::coroutine(boost::coroutines::attributes&)' >
this comes from boost.asio and 'coroutine<void()>' is the old coroutine interface (deprecated)
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
--
Carlos Miguel Ferreira Researcher at Telecommunications Institute Aveiro - Portugal Work E-mail - cmf@av.it.pt Skype & GTalk -> carlosmf.pt@gmail.com LinkedIn -> http://www.linkedin.com/in/carlosmferreira
--
Carlos Miguel Ferreira Researcher at Telecommunications Institute Aveiro - Portugal Work E-mail - cmf@av.it.pt Skype & GTalk -> carlosmf.pt@gmail.com LinkedIn -> http://www.linkedin.com/in/carlosmferreira
--
Carlos Miguel Ferreira Researcher at Telecommunications Institute Aveiro - Portugal Work E-mail - cmf@av.it.pt Skype & GTalk -> carlosmf.pt@gmail.com LinkedIn -> http://www.linkedin.com/in/carlosmferreira
--
Carlos Miguel Ferreira Researcher at Telecommunications Institute Aveiro - Portugal Work E-mail - cmf@av.it.pt Skype & GTalk -> carlosmf.pt@gmail.com LinkedIn -> http://www.linkedin.com/in/carlosmferreira
-- Carlos Miguel Ferreira Researcher at Telecommunications Institute Aveiro - Portugal Work E-mail - cmf@av.it.pt Skype & GTalk -> carlosmf.pt@gmail.com LinkedIn -> http://www.linkedin.com/in/carlosmferreira
participants (7)
-
Carlos Ferreira -
Gavin Lambert -
kwanti -
Lars Viklund -
Nat Goodspeed -
Nathan Ridge -
Oliver Kowalke