- Boost - lists.boost.org

Re: Asynchronous I/O
by Don G 24 Mar '05

24 Mar '05

Hi Hans, Robert and Patrick, My comments are below. Hans Malherbe wrote: > The main thread does the waiting. > > In Windows NT you will either wait on the event flag > in the OVERLAPPED structure or specify a completion > routine and wait in an alertable state with the > SleepEx or one of the *WaitFor*ObjectsEx functions. That makes sense, and I have used that feature before. The hard part about putting this technique to use in a library is that it makes requirements on the behavior of main: it must be in an alertable wait. If I recall correctly, GetMessage/PeekMessage are not alertable. Robert Ramey wrote: > Windows has the concept of "Overlapped I/O" which > permits dispatch of an i/o request that invokes a > callback when done. > > Posix has aio which functions (I believe) in a > similar way. > > So one has the concept of asyncronous i/o without > any explicit reference to threads at least at the > application level. Yes, you are correct; this is a terminology challenged area for me<g>! In this case as well as the above, the application has to wait for completion in the correct manner - not so good for a library IMHO. Patrick M�zard wrote: > By the way, there were and will be lengthy > discussions about which approach is the "best" to > build scalable concurrent programs. I think that > multithreading and event-driven programming were > proven to be equivalent from a theorical point of > view, but there real differences in implementation. It's so hard to find the "best" isn't it? :) Of course, there is seldom a consistent "best" even when an objective measure can be produced (which is almost never) because the result depends so greatly on the scenario or use case. Perhaps the key ingrediant to "best" is "widely used" or "commonly accepted". If you pause to think about it, a standard technique (that wasn't gratuitously inefficient) that everyone could just use would be better (IMHO) than a more optimized, but niche/non-portable technique. Thanks all! Don __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

3 2

[typeof] submission updated
by Arkadiy Vertleyb 24 Mar '05

24 Mar '05

Hi all, The typeof submission in the Boost sandbox file vault has been updated to include a fix allowing faster compiles with GCC (in emulation mode), as well as a workaround for what seems to be remains of ETI bug in VC71. Please take it at: http://boost-sandbox.sourceforge.net/vault/, typeof.zip. Regards, Arkadiy

1 0

Re: Asynchronous I/O
by Don G 24 Mar '05

24 Mar '05

Hi Patrick, Thanks for the links. I looked briefly at the Twisted reference, but since I do not speak python, it was a hard going. :) I will put more effort into it soon. Best, Don --- Patrick M�zard <pmezard(a)gmail.com> wrote: > You should take a look at the python Twisted framework > <http://twistedmatrix.com/>. There are performance issues in python > with > threads because of the Global Interpreter Lock (GIL). The framework > is a > workaround, performing every task in an asynchronous way from a > single > thread. The design of the Defer class is interesting and is the key > of > asychronous tasks control flows > (<http://twistedmatrix.com/projects/core/documentation/howto/defer.html>). > > By the way, there were and will be lengthy discussions about which > approach is the "best" to build scalable concurrent programs. I > think > that multithreading and event-driven programming were proven to be > equivalent from a theorical point of view, but there real > differences > in implementation. You could read this one and many items from its > bibliography too: > > <http://capriccio.cs.berkeley.edu/pubs/threads-hotos-2003.pdf> > (The Capriccio project was really interesting too, on the paper. I > do > not know where they are now). > > Patrick M�zard __________________________________ Do you Yahoo!? Yahoo! Sports - Sign up for Fantasy Baseball. http://baseball.fantasysports.yahoo.com/

1 0

Why do we build debug variants of our compiled libraries?
by Doug Gregor 24 Mar '05

24 Mar '05

Looking at the Jamfiles for Signals, Python, and the other libraries in Boost that have compiled parts that users link against, I'm wondering why we create so many variants by default. Why would a user want to link against the debug version of Signals, for instance? The only reason I imagine would be to debug Signals, but I should hope that the average user does not need to debug that code. If I dig around /usr/lib and /usr/local/lib on my Mac, I only find optimized libraries: nobody else seems to bother building debug variants, so why should we? Anyway, my recommendation is that we stop building debug variants of compiled libraries by default. It's easy for the user to build them if they are really required. Doug

3 2

[iostreams] gcc failures
by Vladimir Prus 24 Mar '05

24 Mar '05

Jonathan, your iostreams library fails all tests on gcc-3.2.3-linux and gcc-3.3.5-linux. See, for example: http://tinyurl.com/4d8we The failures are not marked as expected so: 1. Do you know about them? 2. Is it possible to fix them? Or mark them as expected? I get the same problem locally, so can test any patches, if you don't have those specific version of compilers. Thanks, Volodya

2 2

FSM review
by Jonathan Turkanis 23 Mar '05

23 Mar '05

I vote to reject the FSM library because I find the rationale for not providing better performance insufficient. Specifically, I am not convinced that the framework could not have been implemented to use static dispatch, constant-time dynamic dispatch or some combination of these and the current approach. Normally, before voting to reject a library I like to study the implementation thoroughly so I can make concrete proposals about how it might be improved. I haven't had time to do this with the FSM library, but I would still like my view to be known. I'll start by going through the relevant portions of rationale.html; then I'll answer the review questions. ------- * Introduction. The nine requirements are well-stated, and I accept them. * Dynamic configurability. I agree with the argument for not making all state machines dynamically-configurable. However, the documentation does not explain why it would not be possible to support both dynamically-configurable and non-dynamically-configurable state machines in the same framework, the way xpressive supports both dynamically and statically specified regular expressions. However, I don't consider dynamically-configurability essential, so I'm satisfied with the library in this respect. * Speed versus scalability tradeoffs. Here there is a big problem. I accept that there must be a speed versus scalability tradeoff; in fact, I'd be slightly surprised if there weren't. However, I would normally expect a slow-down of at most a few percentage points when using a framework; I find it stunning that the difference in performance between hand-written machines and framework-generated machines is so significant (10ns/10ns vs. 130ns/220ns), even in a "somewhat unrealistic" test case. In order to accept this performance gap I would need a very convincing explanation. Instead, the explanation seems to be of this form: "The requirements are X; I tried hard to satisfy X without compromising performance, but I couldn't; therefore, it can't be done." Even if we accept that the author really has tried all known techniques, it is important to document what was tried and why it doesn't work, since many library users are sure to be surprised by the performance difference and wonder whether it represents a flawed design. The explanation of why the performance difference shouldn't matter is also unconvincing. I'm particularly disturbed by the implication that FMSs should not be used for parsing. Why not? I have a candidate application of FMSs which is very similar to parsing. I'm currently modifying the Iostreams library to accommodate non-blocking i/o, and I have come to see that many filters can be thought of as state machines. The fact that a dispatch may involve a linear serach involving an RTTI check at each step immediately rules out use of the FSM framework to implement filters, since this search would have to be performed for each character. So if I want to benefit from the FSM abstraction, I would have to write my own framework. I don't see why this should be necessary. * Double dispatch. This seems like it should be a subsection of "Speed versus scalability tradeoffs" - Acyclic visitor: I accept this explanation. - GOF Visitor: It's natural to ask why a complex state machine can't be broken up into several parts which don't know much about each other, each of which uses a more efficient form of dispatch. Less efficient dispatch would be needed only at junctions between the separate parts. Dave Gomboc raised a similar point, and I don't think it has been adequately addressed. - Two-dimensional array of function pointers. This explanation makes no sense to me, even as supplemented by Andreas's reply to Iain Hanson this morning. It's common for a composite component to make use of several components implemented in different TUs. For instance, the composite commonent may "know about" the other components by derivation, by containment, typelists, etc. When it needs to assemble the array of pointers, it can simply ask each of them for their contribution. If there are order of initialization problems, the arrays can be allocated on first use. ------- In my experience, C++ provides extremely fine-grained control over which parts of a computation are performed at compile time and which at runtime. I have a strong suspicion that a FSM library could be written which satisfies the nine requirements and also provides ruthless efficiencies, at least in many common cases. It may turn out to be necessary to sacrifice performance for some FSMs, but I believe I hybrid approach may be possible which uses fast dispatch in the majority of cases. I'm willing to be convinced that it is impossible, but I haven't seen a satisfying explanation yet. Pavel Vozenilek wrote: > Here are some questions you might want to answer in > your review: > > * What is your evaluation of the documentation? > How easy (or hard) it is to understand library > features? What can be improved? The documentation is quite good, except that the Rationale is insufficient. > * What is your evaluation of the design? > What features are supported better by > alternative FSMs? What could be added > (or removed) from the library? Since I've already discussed my dissatisfaction with performance, I'll just address the library's user interface. Overall, I find the design very good. Others have complained about use of CRTP or having to forward to declare states, but to me it looks pretty easy to use. I only have a few comments: - The documentation warns that executing code after calling simple_state::transit (and several other functions) can lead to undefined behavior. I believe the library should prevent this from occurring. One approach would be to have the function specify a result which is stored until react has finished executing, and then acted upon. Another possibility would be to give result move semantics, so result instances can't be stored in local variables and returned later. - The restriction on event deferral -- one must pass an event pointed to by an instance of intrusive_ptr -- is extremely inelegant: int main() { myMachine.process_event( *boost::intrusive_ptr<Event>( new Event() ) ); } I'm sure there is a good reason for this restriction, but there must be a cleaner way to accomplish the same thing. - The procedure for posting events from inside entry actions looks messy; this is noted in the docs, and it's not nearly as bad as the syntax for event deferral, but I'd like to see it improved. - I don't understand why it is necessary to pass a type as a length-one mpl::list simply because it is a class template instantiation. The docs say it is "due to some template-related implementation details", but this sounds fishy to me. > * The library documentation contains > few not yet solved issues (name, > separating the library into two parts, > exception handling). What is you opinion here? I have no opinion. > * What is your evaluation of the implementation? > Are there parts of code too obscure or > duplicating exiting Boost functionality? > Can something be factored out to standalone > library or among general utilities? Unfortunately, I only had time to glance at the implementation. > * Are there performance bottlenecks? > Does the library design fit requirements > of real-time systems? How is it useable > for embedded systems? > Is the documentation clear on performance > tradeoffs? See above. > * What is your evaluation of the potential > usefulness of the library? Useful, judging by the comments of reviewers who are actually using the library. > Can you compare this FSM to other implementations? No. > * Did you try to use the library? With what > compiler? Did you have any problems? > Do you have tips for better support of older > compilers? What are possible portability problems? I ran the regression tests on seven compilers, with the following results: 1. VC7.1 -- passed all tests 2. VC8.0 -- passed all tests 3. VC7.0 -- ...failed updating 36 targets.. ...skipped 144 targets... ...updated 506 targets... 4. GCC 3.4.1 (Cygwin) -- passed all tests 4. GCC 3.2 (MinGW) -- passed all tests 5. Intel 8.0 ...failed updating 4 targets... ...skipped 4 targets... ...updated 678 targets... 6. CW 8.3 ...failed updating 28 targets... ...skipped 112 targets... ...updated 546 targets... 7. Borland 5.6.4 ...failed updating 36 targets... ...skipped 144 targets... ...updated 506 targets... I'd be happy to send the full error messages. > * How much effort did you put into your > evaluation? A glance? A quick reading? In-depth study? Probably about six or seven hours studying the documentation, reading the review comments and preparing my review. > * Are you knowledgeable about the problem domain? I'm not very familiar with FMSs, but know quite a bit about other formal models of computation such as DFAs and Abstract State Machines. > Pavel Vozenilek > FSM review manager Jonathan

4 25

Documentation bug in boost::any
by Michael Goldshteyn 23 Mar '05

23 Mar '05

There is a bug in the sample code which cause me a lot of grief in understanding how boost::any functions, this morning. At: http://www.boost.org/doc/html/any/s02.html The code: --- bool is_string(const boost::any & operand) { return any_cast<std::string>(&operand); } should read: bool is_string(const boost::any & operand) { return any_cast<std::string *>(&operand); } --- Notice the addition of the asterisk. Thanks, Michael Goldshteyn

2 5

RE: [boost] Why do we build debug variants of our compiled libraries?
by Brian Braatz 23 Mar '05

23 Mar '05

Some thoughts below > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Doug Gregor > Sent: Wednesday, March 23, 2005 8:23 AM > To: Boost mailing list > Subject: [boost] Why do we build debug variants of our compiled libraries? > > Looking at the Jamfiles for Signals, Python, and the other libraries in > Boost that have compiled parts that users link against, I'm wondering > why we create so many variants by default. Why would a user want to > link against the debug version of Signals, for instance? The only > reason I imagine would be to debug Signals, but I should hope that the > average user does not need to debug that code. > > If I dig around /usr/lib and /usr/local/lib on my Mac, I only find > optimized libraries: nobody else seems to bother building debug > variants, so why should we? > [Brian Braatz Writes:] At least when I use signals (and other libraries) I always build against the debug for development. While I may not be debugging signals specifically, I may be wanting to see: 1- Signal calls on the call stack in my IDE 2- How my code is using signals - i.e. the focus is on MY code, but being able to step in and out of the signals stuff *=(or any boost lib for that matter) helps me see how my code is working WITH it 3- You may recall I am the same guy who occasionally begs\whines\offers to wash your car FOR: some kind of metadata in signals, I the reason is when you use this lib extensively, you may have a hard time figuring out WHERE something came from. Occasionally, I step into signals and look at the internal data to figure out where the slot came from > Anyway, my recommendation is that we stop building debug variants of > compiled libraries by default. It's easy for the user to build them if > they are really required. > > Doug [Brian Braatz Writes:] Are you just talking about when you do a bjam build of boost (or specific lib)? I use the debug from this mode, but would be happy to change my script to pass in an extra param. The NICE thing about the "build everything" model is it is a catch all for peoples usage.

3 2

Sun C++ regression tests missing?
by Peter Dimov 23 Mar '05

23 Mar '05

Where did our Sun C++ test results go? I wanted to make sure that I haven't introduced any regressions with my latest changes to bind. -- Peter Dimov http://www.pdimov.com

6 17

RE: [boost] Re: boost::iostreams: only with std::cout?
by Dirk Griffioen 23 Mar '05

23 Mar '05

Hi Jonathan, Thanks for helping me out!! I've tried your proposition below and it does the trick, even with actual encryption going on: out << "test" << std::endl; //this works //out << "test" << "\n"; //this does not One remark: he code above works on my vc71 debug setup (cl called through bjam v2 build v10), but if I read your earlier mail correctly it should be the other way around and hang as well? One question: is this behaviour intended? I will try some more stuff (with some other containers , the copy/adapt etc) and source/sink - apart from encryption I am in need of a audio source/sink. I'll let you know :) - It's great stuff! Cheers, Dirk (Sorry the code didn't compile, forgot to match the filter names). (And what do you mean by 'red herring' ? :) -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Jonathan Turkanis Sent: Tuesday 22 March 2005 22:32 To: boost(a)lists.boost.org Subject: [boost] Re: boost::iostreams: only with std::cout? Dirk Griffioen wrote: > I would love to use the boost::iostreams lib, so I created a filter > (which, in this case, does encryption) > > but instead of passing it std::cout I would like to pass it some other > stream, a stringstream for instance (or any kind of ostream/istream, > depending on the direction). > However, I was very surprised to find the following code taking 100% > cpu and not returning. It probably means I did something wrong, but I > can't seem to find it. Here's a cleaned up example that reproduces the bug (when endl is replaces by "\n"). It seems the filter is a red herring. Jonathan #include <iostream> #include <sstream> #include <boost/iostreams/filtering_stream.hpp> int main() { boost::iostreams::filtering_ostream out; std::ostringstream os; out.push(os); out << "test" << std::endl; //out << "test" << "\n"; std::cout << os.str(); } _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient, any disclosure, copying, use, or distribution of the information included in this message and any attachments is prohibited. If you have received this email in error please notify our system management at postmaster(a)optiver.com and immediately and permanently delete this message and any attachments. ********************************************

4 3