April 2005 - Boost - lists.preview.boost.org

Re: [network] An RFC - updated
by Don G 24 Apr '05

24 Apr '05

Hi Peter, > FD_SETSIZE only applies to select, and nobody > uses select except in "quick and dirty" servers > (as I did recently). Sadly, select is by far the most portable solution. On Windows, it is the only solution for 9x/Me. We can and should write more efficient impls for platforms that support poll() or epoll() or kqueue, etc.. > The idea of an explicit poll() call is to allow > the implementation to use a single-threaded > dispatch mechanism (select/epoll/kqueue), if one > is available. Without poll() you are forced to > use worker thread(s) and a callback queue to > support a single-threaded application, and this > can be considerably less efficient than > epoll/kqueue (or select in the < FD_SETSIZE > case) (in theory). Yes, indeed. Though I may be missing something in your idea about net::poll(). How would it avoid a queue? > Of course, if the threaded model can be > demonstrated to achieve comparable performance, > there would be no need to complicate the > interface with poll(). The "need" is performance and familiarity (IMO). If performance were taken out of the picture, it would be hard to argue for it. I don't know how the comparison would go which is why I was writing some stuff to try it out and get some measurements. Best, Don __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Re: [network] An RFC - updated
by Don G 24 Apr '05

24 Apr '05

Hi Peter, > I see that you are slowly moving away from your network-centric > scheme after you've already convinced me of its merits. ;-) Not exactly. Just trying to explore it completely :-) In other posts I state that my thinking is still as I originally proposed. I just see some use cases where your approach has merit; perhaps it is best left to the app but could be provided as a library of its own. Best, Don __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Re: [boost] Re: TR2 and C++0x heads up
by JOAQUIN LOPEZ MU?Z 24 Apr '05

24 Apr '05

----- Mensaje original ----- De: Thorsten Ottosen <nesotto(a)cs.auc.dk> Fecha: Sábado, Abril 23, 2005 11:32 pm Asunto: [boost] Re: TR2 and C++0x heads up > "Beman Dawes" <bdawes(a)acm.org> wrote in message > news:6.0.3.0.2.20050422110501.042b2a20@mailhost.esva.net... > > | So far there are plans to propose Boost.Threads, > Boost.Filesystem, and > | Boost.Signals. As well as proposals for some of the more major > libraries, I > | personally hope someone will do a sweep through Boost looking at > some of > | the smaller utilities and helpers for a possible "Small Additions" > | proposal. > > I believe Alisdair was considering to work on boost.format. > > Besides, boost.date_time I think these other libs are good > candidates (maybe > with slight modifications): > > 1. conversion > 2. optional > 3. string algorithms > 4. utility > 5. variant > 6. iostreams > I'd add a tokenizer to the bunch. Not specially sexy but massively helpful --the typical impulse of a beginner is to do the tokenizing stuff by hand, many a time resulting in off-by-one errors, mishandling of unexpected separators etc. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 2

Patch for bug in boost/boost/iterator/zip_iterator.hpp
by mstone＠cs.swarthmore.edu 24 Apr '05

24 Apr '05

boost/iterator/zip_iterator.hpp has an incomplete #include guard. This patch adds the necessary define to avoid redefinition errors when zip_iterator.hpp is included more than once. Michael

2 1

lists.boost.org not updated
by Peter Dimov 24 Apr '05

24 Apr '05

http://lists.boost.org still links to the old archives. -- Peter Dimov http://www.pdimov.com

1 0

[smart_ptr] sp_counted_base_cw_x86.hpp for release?
by Rene Rivera 24 Apr '05

24 Apr '05

Peter, Should I add the sp_counted_base_cw_x86.hpp implementation in or not? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

3 3

como toolset failures
by Bronek Kozicki 24 Apr '05

24 Apr '05

I think that big part of failures in como toolset are due to --a (strict mode) option. This unfortunatelly prevents windows headers from being included. Or more precisely, the exact reasult of including windows headers with --a option on is that compiler chokes on __declspec, which is exactly what I see in results. I'd rather not update como toolset to remove this option, maybe someone more familiar with bjam will do this. B.

3 3

Is there an IRC channel discussing boost?
by Schrom, Brian T 24 Apr '05

24 Apr '05

I did a modest amount of Googling and looked through the website for an IRC channel. Did I just miss it, or is there not one? Thanks. Brian S.

3 2

Re: [network] An RFC - updated
by Don G 24 Apr '05

24 Apr '05

Hi Michel, >> The reason I suppose that I preferred not-yet-connected >> as a state of stream (vs. a separate class) is that it >> is logically a 1-to-1 relationship (and even the same >> socket) whereas acceptor is a 1-to-N relationship (the >> acceptor socket never becomes something else). > > I don't see connector as 1 to 1 concept. You can use a > connector to establish several connections to the same > address or endpoint if that is needed. The connector > pattern can be used to model fail over between > different endpoints providing the same servcie, by > having a service_connector implementation that wraps > and coordinates several alternate connectors to > different end points over potentially different > transports. This also hides/abstracts the fail over > strategy new endpoint selection in a nice way from > the protocol handler and stream. I see this as something useful, but at higher level than what I am proposing. That may be just because I have never needed anything like it. ;) In all my own uses of connection establishment, it has been one-off connections. Occasionally, I need to reconnect to the same server, but I have always done that with the address object in my proposal. >> The other reason I went with the approach I have is >> that there is only one object to deal with for cancel. >> I don't need to worry about the transition from >> connecting to connected when I want to abort. > > The exact ownership of the socket/handle is always > clear either the connector owns it during the > connection phase and when it's connected the > ownership is transferred to the stream. So I don't > see this as a potential problem. The scenario I am describing goes along with the above statements on single use: I want to do an HTTP get. I first connect, then write, then read. If I decide to cancel, especially with threads in the mix and using blocking style, I must know that I am blocked on the connector, not the stream. But this is not so easy to "know". I cannot hold a lock while I am blocked on connect. What this does is create a race: the entity wanting to cancel cannot know if the blocking call has just finished or not. Which is why I don't like sync programming anymore! ;) I see the granularity as not getting along well with the desire to cancel a specific operation that required a connection. This is especially true for reuse of the connector in the environment I just described. I hope this clarifies my concern. I really feel that a granular cancel feature has to be part of the design. Preferably in a way that is MT friendly. :) > Seperating the connection establishment would make the > stream more stateless and have fewer concerns and it > separates responsibility keeping the interfaces easier. > I also doesn't imply inheritance as is the case whit a > connectable stream. You also don't have to handle > questions such as if a stream can be connected again > after it is closed and so forth (and i guess this could > be different in different implementations). The stream still has many states; this eliminates only one. Also, I don't see any (good<g>) reason to reuse streams. That would be particularly bad in a MT scenario. >> Some platforms have socket features that aren't available >> on other platforms. Unix has signal-driven I/O, while >> Windows does not. Windows has event object based I/O, >> completion ports, HWND messages, etc. which are unique >> to it. The common intersection is blocking, non-blocking >> and select. One can write 99% portable sockets code based >> on that subset. > > So basically layer 0 should support this portable subset. Well, I would mostly agree, but I don't think everyone will. One of the goals several people have expressed is the ability to use level 0 wrappers in non-portable ways. What I am proposing is that there be a level 1 that provides a less bumpy, more easily handled, but conceptually very similar interface. This was another reason I don't have a connector object; that concept has no association with layer 0. > You can define FD_SETSIZE to some arbitrary number. On > my FC1 including select.hpp FD_SETSIZE is 1024 so we > will have to handle arbitrary limits in the interface. > On windows select could be implemented using > WSAEventSelect and WaitForMultipleObjects but this will > have to be cascaded to other threads if the set is to > big and in that case handles can be mixed. So either we > have to cater for arbitrary limits, letting the user > implement on top of the limitst. Or remove arbitrary > limits at cost of complexity and probably increased > threadswitching. On Windows, you cannot increase the fd_set size limit, but I think you are correct on Unix that you can increase it. I have never tried because I wasn't sure if that would require kernel recompile<g> and it wouldn't solve my problem even if it were possible. I would not want to do the thread cascade approach (ala Cygwin). I think a much better approach is what I am proposing: hide this detail completely. I am still scratching around in my head for a way to allow true single threaded use (similar to Peter's net::poll suggestion). > Yes the rules must be really clear, and the library > should probably never hold any kind of lock when > calling a user defined callback since that i > genreally very error prone and deadlock creating, but > this also makes it really hard to implement ;) but > also interesting. Yes, quite "interesting" :) And you can remove the "probably" between the "should" and the "never"... ;) Best, Don __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

Use of Other Languages in Boost Tools
by Allen 23 Apr '05

23 Apr '05

Dear All Boosters, I am glad to read about Buildbot on the boost.devel group. It is definitely important for improving the regession test of Boost. However, A question comes into my mind then. As we all known, Boost is a pre-standard versatile C++ library for C++ programmers. Obviously all the Boost libraries are written in C++ themselves. However, for tools used in Boost (such as the Boost.Jam, Boost.Build, Boost.Book, etc.), the point is not clear, for they are not intended to be included or invoked by C++ programs directly. I saw that Buildbot is written almost completely in Python, for example. I am confused that shall we consist of writing all the Boost tools in C++? Or they can be written in any other languages such as shell scripts, Perl, Python, or even Java, C# or whatever convenient? I must declare that I am not a C++ purist or monomania.:) I have no intent to depreciate any of the languages other than C++, nor depreciate any of the valuable work done by Boosters. I just *wonder* what is the distinction between Boost libraries and tools exactly, and whether there is a rule we should follow for the development of Boost tools. For example, we now use the Boost.Jam and Boost.Build for our "official" build system. I believe that the goal of the Boost.Jam and Boost.Build is to provide a convenient, best and "standard" way for building C++ programs. However, as a *tool* (which is different from a *library*), one may not care about what language the Boost.Jam itself is written in. Nevertheless, suppose we were using Java Ant for building later, will it be acceptable? (of course, take Java Ant as an example here may be inappropriate.) The obvious two attitudes I can imagine are: (1) Prohibit *extensive* use of other programming languages in Boost tools, for example writing a complex tool in Python completely. (Convenient and small scripts are acceptable.) For we are establishing the Best Practice *in* C++ and *for* C++. In addition, the tools can be extensible and reusable with an API for C++ programmers as *developers* not just as *end-users*. (2) Allow extensive use of any convenient and reasonable programming languages in Boost tools. Maybe there should be a list for acceptable languages other than C++, for example shell scripts, Perl, Python, Ruby, etc. For they are just *tools*, not C++ *libraries*. They are just black boxes to C++ programmers, and we do *not* provide the tools as an extensible tool platform/framework with API for C++ developers/programmers for further extension or reuse. I tend to support (1), it seems to me more attractive. Boost.Wave is a good example in my opinion. It is both a practical *tool* related to C++ and an excellent extensible and reusable C++ *library*. I know that we should do the correct thing using the appropriate tool. There is no one language can rule them all.:) I am not crazy to imagine rewriting everything using C++. However, I do believe that we should concentrate on developing C++ libraries and *C++ tools* in our C++ Boost Project. As for Buildbot for example, maybe it is unwise to seek for a C++ replacement for it (for interpreted languages / scripts may be the correct choice), however I worry about that it has nothing to do with C++ or most Boost C++ programmers except that it is used by Boost Regression Test. Any comments are welcome, but NO flames or language-wars pls.:) Best regards, Allen

2 1