March 2011 - Boost - lists.preview.boost.org

Re: [boost] [Boost-users] [context review] Review starts today, Mars 21st 2011
by Oliver Kowalke 24 Mar '11

24 Mar '11

> On Wed, Mar 23, 2011 at 4:07 AM, Oliver Kowalke <oliver.kowalke(a)gmx.de> > wrote: > > > I've published an alternative version of boost.context - the user can > decide in its code which implementation should be used. I think I follow Vicentes suggestion - boost.context provides only one class (boost::context<>) which preferes fcontext(asm) implementation if available otherwise ucontext/fiber. I'll implement a test-app in order to check how this design influences UNIX signal handling (hopefully the impact will be only to require not to change the UNIX signal mask in context<>). > I certainly wouldn't ask you to try to implement these higher-level > features in assembler. But I don't see why the library couldn't add > C++ header files providing such features wrapped around the (assembler > or native) underlying functionality. It would require to do an additional allocation and it might be that the higher implementations can do it more efficient/better suitable for there purposes/not required by some higher libs. Otherwise those libs would pay for the additional memory allocaton even if it would not be required. > We will want features such as templatized callables and exception > support in every higher-level library built on top of Context. Must > every such library provide its own redundant, inconsistent > implementation? The higher libs can implement what they want and how they want. > Here are two different objects initialized in different ways, > containing different state. Maybe they should be different classes? I think they should not be different - both do the same (jumping to other context). The difference is only the one does and the other doesn't manage a stack - but bot represent an execution context. > Perhaps you're saying that the same wrapper machinery that handles a > templated callable could provide an outermost try/catch(...). That > wrapper, guaranteed not to throw a C++ exception, will be executed by > the top-level function passed to Context. > > Again, every realistic consumer of Context will need this... I can add an additional trampoline function which has a try/catch-all block and issues an assertion if an exception was thrown. But this adds an additional indirection! > Okay, there's a default-constructed stack object which manages no > memory, a stack object managing a memory area which is potentially > useful for a processor stack, and a stack object managing a memory > area actually in use by a processor stack. I'm still unclear on the > usefulness of the first kind, a default-constructed stack object. The first is required to be able to jump from any position in the code to the second kind of context (which starts a new execution context). > Sure! As I said, unless one selects the 10.4u (or earlier) SDK, the > ucontext.h implementation should work. I haven't yet tried to build > the Context library; is the ucontext.h implementation header-only? yes regards, Oliver -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

1 0

GSoC Proposal Preparation For Encoding Awared String
by Soares Chen 24 Mar '11

24 Mar '11

Hi all, I am an undergraduate student from the National University of Singapore and I am interested to take part in this year's GSoC with the Boost community. Currently I am preparing my proposal to add support for encoding awareness in string through new/existing Boost project, but there are some questions I would like to ask to clarify the community's interest in such a project. The inspiration I get came from several lengthy discussions I found in the Boost mailing list archive, which happened recently from mid January to mid February. [5][6][7] For a brief overview according to my own understanding, the heated debates was mainly around different ways to ensure consistency between the encoding expected when library code accepts strings, and the actual encoding of strings passed by users. The problem arise because a small minority of developers use std::string in different encoding than UTF-8, and the implicit assumption of UTF-8 encoding for std::string brings inconsistency and causes numerous bugs that are outside the scope of the Boost library. >From the discussion, I found several proposals that have been made to solve the inconsistencies of std::string encoding: 1. Create new classes that warp around std::string, std::u16string, and std::u32string for each encodings and ensure encoding correctness simply through C++ type safety features. The classes are tentatively called the utf*_t classes (which many disliked the name) - Proposed by Chad Nelson with working prototype available. [1] 2. Continue to strongly enforce the assumption that all std::strings are UTF-8 encoded. Depreciate or make it hard to use other encodings in std::string. 3. Reinvent std::string and introduce boost::string. The new string class is proposed to be immutable but also delegate the encoding awareness to templated view<> classes that warp around boost::string, which IMHO the view<> classes share similarity with proposal (1). [7] Now I try not to go into the details and pros & cons of each proposal to avoid turning this thread into yet another string discussion. The original discussions have 542 messages in total, spanned a whole month, and I failed to find any conclusion that everyone could agree on. What I notice in the discussions is that there are several groups of people that have strong opinion on different ways to solve the problem and could not generally agree with each other. I also found that the discussions often drifted away and lose focus on the original problem, but every now and then someone would mention the problem again and proposed a solution that is similar to earlier proposals. Nevertheless, the discussion was extremely informative and insightful. I learned a lot by just reading through these discussions. But since I intend to start a GSoC project based on this subject, I hesitated on what I should really do in this project as I feel that there is no general agreement on how to solve this problem in the Boost community. Although I have some ideas and I personally lean towards proposal (1) by Chad Nelson, I think it'll be best if my project can fit in the interest of majority of the Boost community members. I think it is also best to avoid any further discussion on this topic to actively make the design decision, as the time period for GSoC is limited and the discussion tends to be never-ending. I think there are several options that I can choose for my project: 1. To use Chad Nelson's code as base, try to incorporate other ideas proposed in the mailing list, integrate with Boost.Locale, and make it Boost quality to submit for review. If this option is chosen, I wish that Chad Nelson can be my mentor. 2. To start a new code base, gather and compile ideas suggested in mailing list, final design decisions made by me and my mentor but not the community (to keep the project going on fast), make it Boost quality and submit for review. 3. To start the boost::string project, where another better string is reinvented and fix all the weaknesses of std::string. 4. Adopt different proposal, and improve on existing project such as Boost.Unicode [2] or Boost.Locale [3] such that it really solves the encoding awareness problem. 5. Any other suggestion? I hope to get feedback from you on what should I really focus on in this project. Of course I also hope that this subject is mature enough to be accepted as GSoC project as I can see great interest in the community to solve this problem. I would also like to clarify again that I do not intend to solve actual Unicode handling problems in this project - there are already excellent libraries such as Boost.Locale designed for it. My main objective is to design a set of interfaces that help to ensure encoding correctness and consistency when strings are being passed between different functions. I look forward for anyone that is interested in this project and is willing to be my mentor. Lastly, I apology for my grammar and any possible misunderstanding that caused by my bad writings. Please do correct me if I have missed anything or misunderstood some aspects. I will write a complete and formal proposal once I hear feedbacks from you. Thank you very much and hope that I can start contributing to the Boost community! Best Regards, Soares Chen National University of Singapore References: [1] The Oak Circle C++ (Unicode) Toolkit, by Chad Nelson. http://www.oakcircle.com/toolkit.html [2] Boost.Unicode, by Mathias Gaunard. http://mathias.gaunard.com/unicode/doc/html/ [3] Boost.Locale. http://cppcms.sourceforge.net/boost_locale/html/index.html [4] Should UTF-16 be considered harmful?, Stack Overflow. http://stackoverflow.com/questions/1049947/should-utf-16-be-considered-harm… [5] Always treat std::strings as UTF-8?, Boost Mailing List Discussion. http://groups.google.com/group/boost-developers-archive/browse_thread/threa… [6] What will string handling in C++ look like in the future, Boost Maling List Discussion. http://groups.google.com/group/boost-developers-archive/browse_thread/threa… [7] [string] proposal, Boost Mailing List Discussion. http://groups.google.com/group/boost-devel-archive/browse_thread/thread/f85… (Sorry for linking the mailing list archive to Google Groups, but I feel that Google Group provides better interface for reading archives for those who haven't read the discussions)

4 5

Asio - is it possible not to remove descriptor from epoll?
by Vlad Lazarenko 23 Mar '11

23 Mar '11

Guys, Is it possible to make ASIO keep descriptor in epoll and not remove it automatically after event is fired (and implement or emulate the same behavior for other mechanisms like select, kqueue etc)? My use case is very simple - I am reading data from multicast socket. One read at a time, always reusing the same buffer. The performance is very critical. Another use case is to give ASIO a null buffer and perform sync read yourself when data is available, in that case you can read from tcp/ip sockets as well. I know that libevent supports this but was not able to find out how to do it with Asio. If it is not available, would someone be able to assist in adding this feature? Thank you, Vlad -- *Vlad Lazarenko* *Lazarenko.me <http://lazarenko.me>* vlad(a)lazarenko.com <vlad(a)lazarenko.me>

2 3

polygon bugs with contains() and resize()
by Andy Ross 23 Mar '11

23 Mar '11

Hi Luke, I'm wondering if you've had a chance to look at some boost::polygon bugs I've submitted, or if maybe the trac bug database is the wrong spot: https://svn.boost.org/trac/boost/ticket/5312 (wrong result from contains()) https://svn.boost.org/trac/boost/ticket/5358 (bad output from resize()) https://svn.boost.org/trac/boost/ticket/5359 (very slow resize()) All are, hopefully, reasonably high quality bugs with short, dependency-free code included to exercise them. All have been confirmed vs. the code in subversion. The last two (and in particular 5358) are blockers for me right now. What I'm doing fundamentally requires resize(), and so I'm stuck without a solution to at least one of them. Thanks for your help, and let me know if you need any more information. Andy

1 0

[context review] Formal Review
by Artyom 23 Mar '11

23 Mar '11

Hello, This is my formal review. > Please always state in your review, whether you think the library should be > accepted as a Boost library! Yes, it should be a part of boost. (the alternative version with improved f/u-context support) However following issues should be addressed ASAP: 1. Documentation must be improved with much better description, rationale, examples and design notes and description of member functions, stack unwinding in case of context destruction and so on. See notes below. 2. Current build is too verbose. All relevant options should be configured automatically by default without user specifying them. I understand that it is limitation of BBv2 but it MUST be addressed in the official release. Now Full Review: ---------------- > What is your evaluation of the design? I had issues with Design of fcontext/ucontext but it was addressed by Oliver in very fast and I think correct way so I have no more problems with it. Also I have important concerns about verbosity of build system use. I've discussed this before. BBv2 improvements required. > What is your evaluation of the implementation? The heaviest part of implementation is in assembly so I can't say too much. C++ code looks fine. Current issues: Extern "C" required in context_ucontext.hpp typedef void ( * stack_fn)(); should be extern "C" you need to pass pointers to makecontext as extern "C" function. Asm implementations: Add "namespace" names like boost_get_context instead of get_context. It would prevent names collision and in general allows tools like BCP to rename namespace to use two versions of boost library. > What is your evaluation of the documentation? This is the weakest point of this library. The documentation is not sufficient. What do I miss: a) Context destruction and unwinding. When I tried to implement yield like iterator I had problem with unwinding the stack of auxiliary context when the program does not get execution. I should add some throwing in yield and some flags to make sure that stack is unwind in destruction of iterator. The behavior should be documented and examples should be provided. I explain more: Consider implementation like ... void iterate() { object foo; // may be not destroyed for(;;) { global_value = local_value++; if(local_value > 100000) return; else my_context.jump_to(other_context); } } ... int operator++() { other_context.jump(my_context); return global_value; } ... iterator it; while(it++ < 10) ; ... Now what happens when other_context does not return execution to my_context when gloabl_value becomes 10. Then foo object is not get destroyed. So I need explicity switch to my_context and throw something to make stack unwind procedure work and foo is not got destroyed. Such things should be documented and example how to use it should be provided (i.e. what is correct way to unwind the stack). b) Design rationale is missing c) I'd like to see comparison of features ucontext and fcontext provide. A table of limitations/implementations/platforms like Limitations\Methond ucontext fcontext Signals ... Performance ... d) Description of member functions of boost::context is too brief. e) Implementation details description should be given. f) Better examples should be provided, I've attached few programs I used to test Boost.Context that implements yield like iterator and using context with Boost.Asio in thread like run and such examples should be given. If you want to use the code of the exapmples, consider them under BSL. g) The option context-impl is removed in alternative version and mistakenly was left in the docs. > What is your evaluation of the potential usefulness of the library? It is useful. I implemented a simple client server using Boost.Asio and Boost.Context that switch contexts on async requests and it was quite easy and straight-forward and brings very interesting paradigm to C++. I also had implemented a yielding iterator and it is was very nice, I like a fact that I have such concepts in C++. > Did you try to use the library? With what compiler? Did you have any > problems? I tested in on Linux x86_64 with gcc-4.4 I had problems that executable crashes using shared object libboost_concept.so and fcontext (when it is not compiled with -fPIC which is correct!) The author confirmed the bug and fixed it, no more problems seen. > How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? I mostly tried to implement several tools like iterator and use it with Asio. I run some benchmarks and was quite impressed with fcontext performance. I spend about 6 hours on reviewing this library I implemented a simple client server using Asio and Context where in one case one side was reading and other writing and in other case it was echo server and client benchmark results were quite nice: Reader/Writeer Asio ------------------- Real-Threads, 2 CPU 0.95s Real-Threads, 1 CPU 1.53s ucontext 3.58s fcontext 2.90s Asio-Async 2.84s Echo Asio ---------- Real-Threads, 2 CPU 12.30s Real-Threads, 1 CPU 6.58s ucontext 7.24s fcontext 5.23s Asio-Async 5.24s So I think it is very good base to start from. > Are you knowledgeable about the problem domain? I hadn't used ucontext and fibers before, but I'm familiar with event driven programming and threading. I have large experience and asynchronous programming and implemented once threading support for MS DOS and for Z80. Additional Unrelated Note: -------------------------- Would you consider to create C version of Boost.Context or create C API. It is very useful to have fast setcontext/makecontext operations in C because it may be useful for too many systems where C API is must easier to integrate then C++. Best Regards, Artyom Beilis

2 3

Missing Documentation on Building and Installing Documentation.
by Stirling Westrup 23 Mar '11

23 Mar '11

I'm currently working with boost 1.46 which I downloaded from the main boost site and installed a few weeks ago, without a hitch. Just now I went to check in /usr/local/share/doc for the boost documentation, and discovered it wasn't installed when I asked bjam to install. So, how do I ask bjam to make the documentation, and to install it? I would like to have a local copy as I'm not always going to have internet access when working. -- Stirling Westrup Programmer, Entrepreneur. https://www.linkedin.com/e/fpf/77228 http://www.linkedin.com/in/swestrup http://technaut.livejournal.com http://sourceforge.net/users/stirlingwestrup

7 14

[random] Major update
by Steven Watanabe 23 Mar '11

23 Mar '11

AMDG I've nearly finished preparing Boost.Random for the next release. Here's a summary of the changes. I still have some minor clean-up, but it's mostly stable. I'd greatly appreciate it if anyone wants to take a look at it. If you have issues with any of this, speak up now, while it can still be changed relatively painlessly. * Synchronized with the new standard. - Many new distributions added: chi_squared_distribution, negative_binomial_distribution, fisher_f_distribution, student_t_distribution, weibull_distribution, extreme_value_distribution, discrete_distribution, piecewise_constant_distribution, piecewise_liear_distribution - Renamed uniform_int and uniform_real to uniform_int_distribution and uniform_real_distribution. - Added members to all distributions: param_type, param, stream operators, comparison operators, min and max. - Allow distributions to be used directly with generators without use of variate_generator. - Changed the meaning of the parameters of geometric_distribution and lognormal_distribution. - Added a second parameter to gamma_distribution. - Added seed_seq and added the corresponding constructors and seed overloads the generators. - Added generate_canonical. - Renamed the engine tempates. e.g. mersenne_twister becomes mersenne_twister_engine. - New engine adapter independent_bits_engine. - Added new predefined engine typedefs: mt19937_64, ranlux[24|48][_base], knuth_b. - Updated seeding algorithms. - Added discard - Use unsigned types instead of signed types in all the predefined engines. * Bug fixes: - linear_congruential_engine could assert because the modular arithmetic was not implemented in all cases. shuffle_output, now called shuffle_order_engine, could cause integer overflow. These cases were not triggered by any predefined engines. - uniform_small_int now actually behaves as documented. * New efficient algorithms for binomial_distribution and poisson_distribution. * Moved all features into namespace boost::random * Complete rewrite of the tests - Use Boot.Test's automatic registration and make better use of its test tools. - Statistical tests of the distributions - Separate tests for each engine and distribution Backwards compatibility issues: * The seeding algorithms have changed. This was unavoidable for compatibility with the standard. Not to mention that some of the existing algorithms were weird and inconsistent. - Seeding with an integer: The behaviour should be unchanged for most generators except lagged_fibonacci and subtract_with_carry (and thus ranlux). - Seeding a generator with another generator: This has been enabled by making all all generators models of SeedSeq. Therefore, if you seed a Boost.Random generator with a non Boost.Random generator, your code will no longer compile. The algorithm has changed, so code using this seeding method will yield different values. - Seeding a generator from a pair of iterators: This implicitly assumed that the elements were 32-bit integers in some places, but not everywhere. I've added this requirement everywhere and updated the algorithms accordingly. The behaviour of generators with a value_type no more than 32 bits should be unchanged, but I have not verified this. I've added tests to make sure that the algorithms can't be changed accidentally. * Renaming: - Whenever I renamed a class, I provided a wrapper with the old name. There are also using declarations in namespace boost for everything that I moved. - The names of a few accessors in the distributions changed. I left both the old and the new names in place. * geometric_distribution and lognormal_distribution: - The behaviour is different at runtime. boost::geometric_distribution and boost::lognormal_distribution provide the old behaviour, boost::random::geometric_distribution and boost::random::lognormal_distribution provide the new behaviour. * Streaming: gamma_distribution has a new parameter, thus text saved with the old version will not readable by the new version. I haven't tried to deal with this. do people consider this important? * variate_generator: variate_generator is now a simple pass through wrapper. Code that assumes that it will adjust the generator's result type to match the distribution will no longer work. This is not an issue with any of the distributions provided by Boost.Random. * Return types: The result_types of some generators have changed slightly. Hopefully no one is depending on it being int instead of unsigned... * has_fixed_range: - This is now always false, as it doesn't appear to be very useful and is excessively cumbersome. Anything that was accessing const_min and const_max without first checking has_fixed_range was incorrect to begin with. I think that covers the breaking changes. If there's anything else, it's probably a bug, and I'll try to fix it. A few thing I know about, but haven't changed: * lagged_fibonacci comparison is not technically correct. It's possible for operator== to return false in some cases where the generators will actually produce identical (infinite) sequences. The probability that this will ever actually happen is very small. (As in 2^{-20000} for lagged_fibonacci607) * Similarly the textual representation of lagged_fibonacci is inconsistent with that used by the mersenne_twister and subtract_with_carry. Changing this would make old records unreadable. In Christ, Steven Watanabe

5 10

[context review] Review - alternative version available
by Oliver Kowalke 23 Mar '11

23 Mar '11

Hi, I've uploaded an alternative version to boost vault (boost.context-alternative_version.zip : http://tinyurl.com/6fpnkro) The documentation is available at http://ok73.ok.funpic.de/alternative/boost/libs/context/doc/html/. changes: - fixed bug for x86_64/sysv/elf assembler file: missing assembler directive .type added - as suggested by Artyom and Vicente: - assembler implementation and native implementation of context switching functions compiled and applied as template arg to context<> -> context<> == context< protected_stack, asm_impl > on UNIX, context< protected_stack, native_impl > on Windows - for Windows assembler implementation is disabled Oliver

3 11

Re: [boost] [Boost-users] [context review] Review starts today, Mars 21st 2011
by Oliver Kowalke 23 Mar '11

23 Mar '11

> I see that Boost.Fiber is on the review queue, but Boost.Tasklet and > Boost.Task are not yet? boost.tasklet will be renamed to boost.strand (see my git repo). because all of those lib require boost.context and hafe to be reqorked (except boost.fiber) the review wizards requested to remove boost.task from the review queue. If boost.context is accepted and in a final state I'll request a review for the other libs. > > 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). > > Note on the alternative implementation: I am not enthused about the > idea of embedding the fcontext decision in source code. I would rather > make that decision externally in the build machinery. I've pulished an alternative version of boost.context - the user can decide in its code which implemention should be used. > void (fn)(void*) and void* vp are very classic-C. While I'm sure there > are those who prefer to work at that level, I'd also want overloads > supporting a templatized nullary callable, like Fiber, plus the > args-for-implicit-bind variant. Hopefully Fiber and other high-level > abstractions implemented on Context could simply leverage Context's > support rather than reimplementing it. Since every library built on > top of Context will want to support those constructs, if that support > can be centralized in Context, it should be. Becuae most of the work is done ins assembler I'd like to keep the things simple as possible. Supporting templatized ctors + args-for-implicit-bind variant would make the assembler too much complicated and thus error prone (different C++ calling conventions on the platforms etc.). So I want to stuck with the C-style callback and track boost.context as a building block for other libs providing higher abstractions. > I'm not sure I understand the usefulness of a context object not > currently associated with a stack object, but I realize that > corresponds with a state designed into the underlying machinery, e.g. > ucontext.h. Oh: the initial current context doesn't manage an explicit > stack. Maybe a base class that represents a context with implicit > stack, and a subclass that represents a context with explicit stack? You have to differentiate between a context created to execute a new execution context (the ctor accepting funtion, stack etc.) which manages its own stack (passed as argument) and the context instance grapping the current execution context (default ctor) which collect the CPU state but does not manage the current stack because it its already managedd by the operating system (in the case of main()-function for instance) or by another context create by its ctor with protected_stack instance as argument. void main() { ... // ctx1 grapps the current CPU state // but does not manage a stack because the // current stack belongs to the operating system/process context ctx1; // ctx2 represent a new execution path executing my_fn() // it manages its own stack context ctx2( my_fn, 0, protected_stack( 65536) ); // now we jump from the curretn execution context ctx1 // to the new execution context ctx2 which will execute // function my_fn() ctx1.jump_to( ctx2); // we return from my_fn() == jumped out of execution context ctx2 // back to ctx1 ... } ctx1 pin-points (you could have mutliple) a specific point in the code/execution path. > (Is the static variable that underlies boost::context::current() > thread-local?) context has no static variables and no boost::context::current() (maybe you are using an old version?). > Fiber-local-storage on Windows: may I suggest a context-local<T> > abstraction for this library, implemented as Fiber-local for the > Windows Fibers implementation and thread-local elsewhere? hmm - this what I want to handle in libs with higher abstractions. So boost.context can be thin as possible. > Exceptions: "must not throw exceptions" may be too limiting. It's hard > for a typical coder to guarantee that no underlying code will throw. > Of course you could require that every fn passed to context's > constructor must have an explicit outermost try/catch(...) -- but > that's the sort of boilerplate that's easy to forget. context could > provide a wrapper containing that try/catch(...). In fact, you could > even use Boost.Exception to propagate any such exception to "somewhere > else" -- perhaps a context user's policy decision? Then one such > policy choice could be "I guarantee no underlying code will throw," > for those anxious to avoid the overhead. The function which is pased as first argument to the ctor of context must not throw. The reason is that it is passed to C-functions (== functions declared as extern "C") and throwing an exception through C-code results in undefined behaviour. > Exception management may feel like a topic best left for a > higher-level abstraction -- but I don't see how that could work. If > the higher-level abstraction is implemented in terms of Context, and > if Context flatly forbids exceptions, how could the higher layer > support them? Exception hamdling should be done by higher abstractions. For instance using packaged_task/future (as shown in boost.tasklet). > On the other hand, if it *is* reasonable for Context to defer > exception support to a higher level, then the documentation should be > revised to state the requirements for that support. I believe yes. > What's the use of a stack object representing not-a-stack? Wouldn't > the abstraction be simpler and more robust if every stack object is > guaranteed to represent a valid stack? That would seem to simplify > some of the semantics of Context as well. stack must support move-semantics -> a moved stack must be represented == not-a-stack. This is usefull for reducing memory allocation/deallocation for stacks. boost.tasklet reuses (== moves) stacks from a context which is finished and caches the stack. If a new context has to created in moves the recycled stack into the new context. That's trhre reason why stack must be move-able. > That said -- I'm a bit concerned that the documentation seems to imply > that stacks always grow downwards. Are we really never going to > encounter machines on which the opposite is true? Shouldn't the stack > concept include some support for directionality? On all platforms I've been working on the stack grows downwards. > The stack concept is fairly dense. Would it make any sense to define > an actual stack abstract base class? Because Context is > template-based, an implementation can (and protected_stack should) > avoid that base class -- but it could provide user stack > implementations with a starting point. because the stack is a template argument of context it represents an implicit interface - so no explicit interface like abstract_stack is required. The current solution doesn't require stakc to derive from a base class. > Thumbs up on providing protected_stack rather than a plain memory area. protected_stack appends a guard page at the end of the stack. This guard page issues sefault/access violation if you acces the address of that page. This is usefull if the size of the stack is too small. Ypou could use your own stack implementation without such a guard page. But if you excced the stack range you overwrite in the worst case the memory of your own application. > Again, the need to account for a context object that isn't currently > managing a stack feels like clutter. see above - pin-point of current execution path/context > The Boost.Coroutines documentation contains a discussion of the > possible unreliability of the GetCurrentFiber() == 0x1E00 trick, and > the value of calling IsThreadAFiber() on systems that support it. I > note some ambivalence in context_fiber.hpp about that. Why is the > IsThreadAFiber() implementation commented out? That is because of the fact that Windows XP + Sevice Pack 2/3 defines _WIN32_WINNT >= _WIN32_WINNT_VISTA but doesn't declare ::IsThreadAFiber(). I didn't found a way to detect XP + SP 2/3 beside of _WIN32_WINNT. > > - What is your evaluation of the documentation? > > At first I was confused about the usefulness of release_stack(). moves the stack out of the context instance for inspection or recycling > The Boost.Coroutines documentation notes that you can save the cost of > ConvertThreadToFiber() and ConvertFiberToThread() per round trip by > explicitly calling ConvertThreadToFiber() beforehand. > context_fiber.hpp is implemented the same way; presumably the same > note could be useful. Or are you assuming that all cycle-conscious > users will select the fcontext implementation instead of the Fiber > implementation? Holger Grund has some concerns regarding exception handling in the assembler implementation of fcontext on Windows. So I've dissabled it - maybe if I could fix it I'll make it available too. > There's a confusing phrase in the description of stack::address(): > "Function void* address() must return the address where the stack > begins to grow downwards (to lower addresses)" -- so far so good, with > a nod to the note above about stack direction -- "and the stack must > be moveable." see my comments above > This seems to say that the Context library might move the block of > memory in which the processor allocates stack frames. But that would > completely invalidate data residing in those stack frames! I *think* > the phrase is intended to mean that any class implementing the stack > concept (the object containing stack pointer and size) must be > moveable. Either way, the intent should be expressed more clearly. > What is that phrase doing attached to the description of > stack::address(), anyway? do refere to moving the stack out of a context? then this don for reusing that memory junk - otherwise the stack get deallocated. > I intend to try replacing that Boost.Coroutines Pth implementation > with a Context implementation. (Those who still care about OS X 10.4 > could then provide a Context implementation based on Pth. However, I > myself no longer care.) If Context is accepted into Boost, It strikes > me that a version of Boost.Coroutines based on Context would be a > useful evolutionary step in the Vault. I'm interessted in porting boost.context to MAC OS X (some first stepps in Jamfiles -> allow ucontext) - unforutnately I've no box running MAC OS X. I hope we can work together. best regards, Oliver -- GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit gratis Handy-Flat! http://portal.gmx.net/de/go/dsl

2 1

[GSoC11] Checks & Hashes
by Mateusz Nowak 23 Mar '11

23 Mar '11

Dear Paul A. Bristow, I'm 3rd year Informatics student at ETI, Gdańsk University of Technology and I'm highly interested in participating in GSoC 2011. I choose boost and "Checks & Hashes" project idea, because it meets with my coding abilities and "always try to make something useful" general rule. I have 7 years experience in programming and algorithms. I would rate my knowledge: c++ 4/5, svn 3-3.5/5. Some questions about the project. As CRC class seems to be only separate hashcodes library in boost, should the rest of algorithms libraries at least try to inherit crc methods naming and parameters convention or, if decision to use completely different convention, the crc library should be adapted or left as it is now? Actual naming idea is that function name should start with algorithm type - if it produces checksum or hash, than algorithm name (sha, crc, ...) and then variant (like in sha: sha1, sha256,...), so sha1 function name will look like h_sha_1, or for "Simple modulo 256 etc check values and digits." it will be c_simple_256. How many algorithms you expect to be found/implemented, documented, tested and got to work more or less? This would help me making work plan. Also i will have exams between 8-21 June, so my commitment to the project at that time will be low. I hope that this won't be a problem. Regards, Mateusz Nowak.

2 1