August 2008 - Boost - lists.boost.org

[thread_pool]: formal review request
by Oliver Kowalke 12 Sep '08

12 Sep '08

Hello, I'd like to request a review of my thread_pool library - it is available at the boost vault/Concurrent Programming. The library provides: - thread creation policies: determines the managemnt of worker threads - fixed set of threads in pool - create workerthreads on demand (depending on context) - let worker threads ime out after certain idle time - channel policies: manages access to queued tasks - bounded channel with high and low watermark for queuing tasks - unbounded channel with unlimited numer of queued tasks - rendezvous syncron hand-over between producer and consumer threads - queueing policy: determines how tasks will be removed from channel - FIFO - LIFO - priority queue (attribute assigned to task) - smart insertions and extractions (for instance remove oldest task with certain attribute by newst one) - tasks can be chained and lazy submit of taks is also supported (thanks to Braddocks future library). - returns a task object from the submit function. The task it self can be interrupted if its is cooperative (means it has some interruption points in its code -> this_thread::interruption_point() ). Oliver -- GMX Kostenlose Spiele: Einfach online spielen und Spaß haben mit Pastry Passion! http://games.entertainment.gmx.net/de/entertainment/games/free/puzzle/61691…

6 9

[smart_ptr] release()
by Phil Bouchard 09 Sep '08

09 Sep '08

As it turns out I think a release() member function should be added to the smart pointer. Its purpose is to give away ownership of the object. See the following pseudo-code: template <typename T> class smart_ptr { ... smart_ptr(element_type *); value_type * get(); element_type * release() { element_type * __p = pointer_ref(); pointer_ref() = 0; if (-- counter_ref()) return 0; else return __p; } }; It follows the same idea of its predecessor auto_ptr<> but will return a null pointer if the object is still shared thus not ready to be deleted. This way the allocator will be much easier to support either by calling this function before deallocate(), inside it or by using a specialized wrapper class to handle it: template <typename T> class allocator { ... typedef smart_ptr<T> pointer; void deallocate(pointer & __p) { delete p.release(); } }; -Phil

6 15

lifetime of ranges vs. iterators
by Arno Schödl 07 Sep '08

07 Sep '08

Hello, some adaptor ranges need certain constant information about their underlying ranges. For example, iterating over a forward "difference_range", the difference between two sorted ranges, requires access to the ends of the underlying ranges. These two additional iterators are constant, they do not change when the difference_iterator is incremented. Now, where should this additional constant information be stored? a) In the difference_range, and each iterator holds a reference to the difference_range? That requires the difference_range to be alive as long as its iterators are alive. This may be difficult to ensure if the difference_range is a temporary. b) In the iterators, so the lifetime of adaptor iterators is independent of the adaptor range. Of course, one can use shared_ptrs and so on, but still the iterators are ultimately responsible to keep that information available. This initially seemed more natural to me, but if implemented naively by storing the additional iterators in the iterator itself, it leads to storage bloat: each difference_iterator needs 4 instead of 2 of its underlying iterators. When stacking difference iterators, the difference in required storage grows exponentially: instead of 2^N, you need 4^N storage... I feel that in order to solidify the range concept, one needs to make a choice whether a) or b) is "standard", because any user of ranges would need to know. Any thoughts on this? Arno -- Dr. Arno Schoedl · aschoedl(a)think-cell.com Technical Director think-cell Software GmbH · Invalidenstr. 34 · 10115 Berlin, Germany http://www.think-cell.com · phone +49-30-666473-10 · toll-free (US) +1-800-891-8091 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl · Amtsgericht Charlottenburg, HRB 85229

7 118

[spirt] question regarding BOOST_SPIRIT_THREADSAFE and BOOST_SPIRIT_SINGLE_GRAMMAR_INSTANCE
by Robert Ramey 05 Sep '08

05 Sep '08

I've just discovered the existence of these manifest constants in spirit and checked the documentation and code to determine what they do. Of course figuring what spirt code does and how it does is not easy to get right for the casual observer so feel free to correct and any mis-conceptions / conclusions that I 've got. My general conception is that parsing can be consider as various quasi - independent phases. a) specification of grammar - source code preparation b) compiliation c) instantiontion/construction of grammar definition d) usage of c) to parse a text string e) destruction of instance. >From this I want to conclude that phase d) does not change the grammar definition so so that in a multi-threading environment, the invocation of the scoped_lock would be limited to phases c) and e). That is, I want to believe that the following example adapted from the spirit documentation would work: const my_grammar g; // note addition of const if (parse(first, last, g, space_p).full) cout << "parsing succeeded\n"; else cout << "parsing failed\n"; The reason I ask is that the serialization library uses spirit to parse xml archives. Recently, I made changes to make the library thread-safe. I did this without using mutexes/locks by confine all non-const operations to construction and destruction and using static object constructed/destructed at pre-main and post main time time. Although the jury is still out on this, I believe it will make the serialization library thread safe without the need for using threading primitives and libraries. I never realised that spirt wasn't thread-safe. I would like this approach to include xml_archives. So my quesion is: Can I instantiate my xml grammar as a static variable at pre-execution time and permit it to be used by mulitipe threads without locking? Robert Ramey

7 13

[review] FSM Second Call for Reviews
by Martin Vuille 05 Sep '08

05 Sep '08

The formal review for Andrey Semashev's Finite State Machines (FSM) library has been running for a week now and continues until the 20th. There have been some lively discussions about the library, but no one has yet entered an explicit yes or no vote. If there are no votes either way, the FSM library submission will be rejected by default. If you wish to review, but don't have time before the review period ends on the 20th, please let me know as it may be possible to extend the review period. And, finally, a reminder to include an explicit "for" or "against" vote in your review. ----------- The documentation (overview and reference) is available online: http://boost-extension.redshoelace.com/docs/boost/fsm/doc/state_machine.html http://boost-extension.redshoelace.com/docs/boost/fsm/doc/reference.html The current submission is available from the sandbox vault at http://tinyurl.com/yjozfn (or http://www.boostpro.com/vault/index.php?action=downloadfile&filename=FSM.zip &directory=&PHPSESSID=48493076c1ea60ae316f7b60f15b9ed1, if you prefer.) There has already been some discussion of the library since the rewiew was first announced: http://www.nabble.com/FSM-Review-Announcement-to18820219.html http://www.nabble.com/FSM-Review-Reminder-to18890305.html ----------- Description ----------- "The main goals of the library are: * Simplicity. It should be very simple to create state machine using this library. * Performance. The state machine infrastructure should not be very time and memory-consuming in order to be applicable in more use cases. * Extensibility. A developer may want to add more states to the existing state machine, and this addition should be relatively safe since it shouldn't interfere with the existing states. The developer should also be able to specify additional transitions and events for the machine with minimum modifications to the existing code." "Boost.FSM vs. Boost.Statechart There is another library in Boost that provides similar functionality: Boost.Statechart. Although it currently covers almost all major Boost.FSM features and provides ones that are not supported in this library, Boost.Statechart is more targeted to creation of big and complex state machines with possibility of distributed development. But this does not come at no price and Statechart has little tools for compile-time programming and does not provide as much run-time performance as Boost.FSM does. So there are main guidelines for users to make a decision between Boost.FSM and Boost.Statechart: [...]" "The following compilers are known to have problems or most likely will have ones: * Microsoft Visual C++ 6.0 and 7.0. Most probably will fail to compile due to lack of partial template specialization support. * Borland C++ Builder 5.5.1 (free version). Fails to compile due to lack of partial template specialization and in-class using declarations support. Some other minor problems also have been noticed. Newer versions of the compiler have not been tested. * OpenWatcom 1.5. Fails to compile due to problems with Boost.MPL code. Newer versions of the compiler have not been tested. * SunPro C++ Compiler 5.5 for Solaris (SPARC). Most likely will show problems with function overload resolution. Newer versions of the compiler have not been tested." The current submission is available from the sandbox vault at http://tinyurl.com/yjozfn (or http://www.boostpro.com/vault/index.php?action=downloadfile&filename=FSM.zip &directory=&PHPSESSID=48493076c1ea60ae316f7b60f15b9ed1, if you prefer.) ---------------------------------- What to include in Review Comments ---------------------------------- Your comments may be brief or lengthy, but basically the Review Manager needs your evaluation of the library. If you identify problems along the way, please note if they are minor, serious, or showstoppers. Here are some questions you might want to answer in your review: 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? And, finally, every review should answer this question: Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Thanks in advance for your participation in this review. MV

7 26

[iostreams][trunk] patch for msvc 7.1 error
by David Walthall 02 Sep '08

02 Sep '08

The following patch fixes the mapped_file_test compilation error for msvc 7.1 (daw-msvc71): Index: libs/iostreams/src/mapped_file.cpp =================================================================== --- libs/iostreams/src/mapped_file.cpp (revision 48407) +++ libs/iostreams/src/mapped_file.cpp (working copy) @@ -434,7 +434,7 @@ void mapped_file_source::close() { pimpl_->close(); } -mapped_file_source::operator safe_bool() const +mapped_file_source::operator mapped_file_source::safe_bool() const { return pimpl_->error() ? &safe_bool_helper::x : 0; } bool mapped_file_source::operator!() const David PS Is this the right place to post patches? Should I use Trac instead?

2 2

Should we provide hot fixes?
by Beman Dawes 02 Sep '08

02 Sep '08

Although it does look like we will be able to hold to a quarterly release schedule, it is really doubtful we have enough resources to issue point releases. To get bug fixes into user's hands more quickly, should we provide hot fixes when appropriate? Hot fixes might work something like this. (I'll use an embarrassing Boost.Filesystem mistake I made as an example.) * Individual developers will decide on a case-by-case basis if they want to provide a hot fix for a given bug. * There would be a prominent link on the web site to a "Hot Fixes" page in the trac. * That "Hot Fixes" page would have a section for each release. * Under release 1.36.0, there would be a changeset number, a description of the problem, and a directory-location: 48192 Restore deprecated basic_directory_entry names inadvertently removed. (boost/filesystem) * The changeset number would link to http://svn.boost.org/trac/boost/changeset/48192 * The "Hot Fixes" page would include instructions on how to apply a changeset. The instructions are the same for all operating systems: -- Click on "Download in other formats: Unified Diff". -- From the command prompt, cd directory-location patch <download-location/changeset_r48192.diff * The "Hot Fixes" page would include instructions on how to install "patch" for popular operating systems, and give an example of actual usage. Comments? --Beman

23 81

[interprocess][process] Synchronizing libraries and efforts (+ bugs)
by Ion Gaztañaga 01 Sep '08

01 Sep '08

Hi to all, I recently needed s library to launch processes and I took a look to the recently announced Process 0.2 (http://lists.boost.org/Archives/boost/2008/07/139322.php) I just needed the library for Windows, and I think the library is interesting although still lacking in some basic aspects (explained later in this post). A process-launching library is a very nice utility for Interprocess and I was thinking of adding this possibility for a future version (Boost 1.37 or 1.38) of the library. If Boost.Process is going forward, it would be glad to collaborate and develop a library that can satisfy all our needs and plays nicely with Interprocess. My main requests for a process-launching library are: 1) Ability to launch a process and a blocking or non-blocking wait operation to obtain its result (Boost.Process already has this). 2) Ability to redirect child process stdin/stdout/stderr to /dev/null, to share the stdin/stdout of the parent or to redirect it to a file. And in the latter case, append or overwrite options (Boost.Process implements some of this options). I slightly modified Boost.Process to implement a rought version of file redirection. 3) Ability to modify the environment variables of the child (Boost.Process already has this). 4) Blocking and non-blocking redirections of stdout and helper functions to simplify its usage (Boost.Process does not have this). For example: bool send_stdio_and_get_stdout (const void* stdin, std::size_t stdin_size, std::vector<char> &stdout); or similar would avoid many programming errors because at any moment stdin can block and we must extract stdout so that the child process can continue processing stdin. 5) I don't know if streams are the right way to communicate with processes, because they don't offer non-blocking support. 6) I think that process-launching interface should be similar to the soon to be standardized C++ futures. So I'm interested in a process-launching library and I offer my collaboration in case Boost.Process development needs help. Regards, Ion PS: Some possible bugs found on Boost.Process 0.2 version (Windows): -> main thread handle returned by CreateProcess in PROCESS_INFORMATION structure the must be closed and I can't find this in the code. -> child::wait function returns sporadic errors when multiple children are launched and waited. I changed the code from: do { ::GetExitCodeProcess(handle_, &code); ::Sleep(500); } while (code == STILL_ACTIVE); ::WaitForSingleObject(handle_, 0); ::CloseHandle(handle_); with ::WaitForSingleObject(handle_, INFINITE); ::GetExitCodeProcess(handle_, &code); ::CloseHandle(handle_); ->environment::set does not correctly overwrite existing variables): void set(const std::string &var, const std::string &value) { insert(value_type(var, value); } should be void set(const std::string &var, const std::string &value) { this->operator[](var) = value; } -> Using named pipes has been problematic because it returns errors when launching multiple processes aggressively: Error 231 - All Pipes are Busy. This does not happen with anonymous pipes and I think it has some relationship with the guid code. By the way, I think a uuid library is too much to create a unique identifier to be shared with the child a simple atomic count would to the job in my opinion. That would reduce Boost.Process dependencies. -> systembuf::close() should call sync() to push the last charaters into the pipe, othewise, characters are lost if the user does not flush the stream. -> I've changed the "stream_info::usefile" case in win32_start to support redirecting to files, changing "CREATE_NEW" parameter of CreateFileA with CREATE_ALWAYS. -> And now, the most important one ;-) Please, avoid tabs! Read boost development guidelines: http://www.boost.org/development/requirements.html#Tabs

3 10

Re: [boost] [review wizard/admin] Not-yet-committed, but accepted libraries
by JOAQUIN M. LOPEZ MUÑOZ 31 Aug '08

31 Aug '08

________________________________________ De: boost-bounces(a)lists.boost.org [boost-bounces(a)lists.boost.org] En nombre de Ronald Garcia [garcia(a)cs.indiana.edu] Enviado el: sábado, 30 de agosto de 2008 18:56 Para: Boost mailing list CC: John R. Phillips Asunto: [boost] [review wizard/admin] Not-yet-committed, but accepted libraries > > A few libraries have been reviewed and accepted into boost, but have > not yet appeared in SVN as far as I can tell. Could some light be > shed on the status of the following libraries? Apologies if I have > simply overlooked any of them: > > Flyweight (Joaquín Mª López Muñoz) I'm glad you ask :) The review raised some important issues that only during this summer I've had the time to attack. I've got everything ready for a post-review version during the following week. My target release is Boost 1.38. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[pointer container] Wishlist: Iterating through nullable vectors and compiler firewalls
by Andrew Hain 31 Aug '08

31 Aug '08

Two quick queries. Would it make sense to have the iterator increment and decrement operators and begin() member function of ptr_vector< nullable<> > skip missing records so that applications have no need to check? What is stopping pointer container classes from being used with opaque types as a compilation firewall? -- Andrew Hain Oasys http://www.oasys-software.com

2 2