[context review] Review starts today, Mars 21st 2011
Hi all, The review of Oliver Kowalke Context library starts today Mars 21st 2011, and will end on Mars 30th. Boost.Context is a basic building block library that is used for more higher abstractions. It is used by Boost.Fiber, Boost.Tasklet and Boost.Task from the same author. I really hope to see your vote and your participation in the discussions on the Boost DEVELOPMENT mailing lists! WARNING !!!!!!!!!!!!! Only on the Boost DEVELOPMENT mailing lists Please use [context review] as prefix of your post to make easier the review follow up. You can download a frozen version for the review from the Vault, TinyURL: http://tinyurl.com/5r77rel or The documentation is available directly here: http://ok73.ok.funpic.de/boost/libs/context/doc/html/ --------------------------------------------------- About the library: Boost.Context provides a possibility to switch between different user-level context and is intended to be the basis for a higher abstraction like coroutine and fiber. A user-level context represents the current execution state, including all registers and CPU flags, the instruction pointer, the stack pointer. boost::context encapsulates such a user-level context and is able to store/restore its associated user-level context. This allows multiple execution paths running on a single thread using a sort of cooperative scheduling (in contrast a thread is preemptively scheduled) - the running boost::context decides explicitly when its yields to allow another boost::context to run (user-level context switching). A context can only run on a single thread at any point in time but may be migrated between thread. A context switch between threads costs usually thousands of CPU cycles on x86 compared to a user-level context switch with few hundreds of cycles. Boost.Context differes to setjmp()/longjmp() in the fact that the C99 standard does not require that longjmp() preserves the current stack frame, e. g. jumping into a function which was exited via a call to longjmp() is undefined. Boost.Context allows to select the mechanism provided by the operating system (ucontext on UNIX, Windows Fibers on Windows) or a faster implementation provided by this library (fcontext using assembler). --------------------------------------------------- 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? Have a good review, Vicente Review Manager
On Sun, Mar 20, 2011 at 8:18 PM, Vicente BOTET <vicente.botet@wanadoo.fr> wrote:
The review of Oliver Kowalke Context library starts today Mars 21st 2011, and will end on Mars 30th.
I really hope to see your vote and your participation in the discussions on the Boost DEVELOPMENT mailing lists! WARNING !!!!!!!!!!!!! Only on the Boost DEVELOPMENT mailing lists
:-( I am not presently on the development mailing list; I am reluctant to register because keeping up with the boost-users list already takes a surprising amount of my time. I have opinions and a bit of experience with the topic area of this library, and I was planning to submit a review. But I feel rebuffed. Perhaps I could submit a review on this list and have you, the review manager, helpfully forward it to the development list?
On Mar 20, 2011, at 9:18 PM, Nat Linden <nat@lindenlab.com> wrote:
I have opinions and a bit of experience with the topic area of this library, and I was planning to submit a review. But I feel rebuffed.
Perhaps I could submit a review on this list and have you, the review manager, helpfully forward it to the development list?
Reviews have always been accepted in many ways - the problem is when *discussion* gets spread between the lists. It's probably best to send a review directly to the review manager (for reposting) in cases like this, to avoid confusion. Gordon
On 03/20/2011 06:18 PM, Nat Linden wrote:
On Sun, Mar 20, 2011 at 8:18 PM, Vicente BOTET<vicente.botet@wanadoo.fr> wrote:
The review of Oliver Kowalke Context library starts today Mars 21st 2011, and will end on Mars 30th.
I really hope to see your vote and your participation in the discussions on the Boost DEVELOPMENT mailing lists! WARNING !!!!!!!!!!!!! Only on the Boost DEVELOPMENT mailing lists
:-(
I am not presently on the development mailing list; I am reluctant to register because keeping up with the boost-users list already takes a surprising amount of my time.
I have opinions and a bit of experience with the topic area of this library, and I was planning to submit a review. But I feel rebuffed.
Nat - I have seen this instruction in a few reviews of late. It is very unfortunate. I believe it is in direct contradiction to the lively discussion we have had at BoostCon on how to improve and foster involvement during reviews. Those discussions always focus on the importance of involving users of libraries and not just the developers of libraries. While many of us subscribe to both lists, I believe the consensus during our "how to make boost better" type sessions for the past two years always resulted in a desire to review libraries on both mail lists. I understand and appreciate the complications that this causes for both for the review manager and duplication of discussion threads in general; however, if the community is going to have separate dev and user lists then it makes sense that the review will have to occur on both lists. Since this plea of one-list-posting has recently surfaced for a couple reviews, it would be helpful if the Review Wizards could chime in with some uniform policy that makes sense for the community. (Thank you Wizards for your time and dedication to the process). michael -- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com
On Mar 20, 2011, at 11:00 PM, Michael Caisse wrote:
Since this plea of one-list-posting has recently surfaced for a couple reviews, it would be helpful if the Review Wizards could chime in with some uniform policy that makes sense for the community. (Thank you Wizards for your time and dedication to the process).
It might also be another argument for creating a reviews-only mailing list, a possibility which has come up in the context of extending review periods and having simultaneous reviews. Gordon
Michael Caisse wrote:
On 03/20/2011 06:18 PM, Nat Linden wrote:
On Sun, Mar 20, 2011 at 8:18 PM, Vicente BOTET<vicente.botet@wanadoo.fr> wrote:
The review of Oliver Kowalke Context library starts today Mars 21st 2011, and will end on Mars 30th.
I really hope to see your vote and your participation in the discussions on the Boost DEVELOPMENT mailing lists! WARNING !!!!!!!!!!!!! Only on the Boost DEVELOPMENT mailing lists
:-(
I am not presently on the development mailing list; I am reluctant to register because keeping up with the boost-users list already takes a surprising amount of my time.
You can unsubscribe or disable mail delivery at any time. You can also disable mail delivery immediately, and use gmane to read the mailing list as you see convenient.
I have opinions and a bit of experience with the topic area of this library, and I was planning to submit a review. But I feel rebuffed.
Nat -
I have seen this instruction in a few reviews of late. It is very unfortunate. I believe it is in direct contradiction to the lively discussion we have had at BoostCon on how to improve and foster involvement during reviews. Those discussions always focus on the importance of involving users of libraries and not just the developers of libraries.
While many of us subscribe to both lists, I believe the consensus during our "how to make boost better" type sessions for the past two years always resulted in a desire to review libraries on both mail lists. I understand and appreciate the complications that this causes for both for the review manager and duplication of discussion threads in general; however, if the community is going to have separate dev and user lists then it makes sense that the review will have to occur on both lists.
Since this plea of one-list-posting has recently surfaced for a couple reviews, it would be helpful if the Review Wizards could chime in with some uniform policy that makes sense for the community. (Thank you Wizards for your time and dedication to the process).
As somebody who asked for reviews on boost-devel only for reviews that I have managed, I think that's a good idea. Having reviews on two different mailing lists would certainly result in the same issues raised independently on two mailing lists, which would make it much harder on the author and review manager, and it's not entirely clear whether there will be any benefits. Note that if somebody wishes to submit a review and does not want to participate in discussion, he can always submit the review directly to the review manager. -- Vladimir Prus Mentor Graphics +7 (812) 677-68-40
participants (5)
-
Gordon Woodhull -
Michael Caisse -
Nat Linden -
Vicente BOTET -
Vladimir Prus