- Boost - lists.boost.org

[1.33.0] Let's start preparations...
by Douglas Gregor 02 Apr '05

02 Apr '05

Let's start revving up to release Boost 1.33.0. Personally, I'd like to get it out the door by mid-April at the latest, and I'm offering to manage this release. To get things rolling, I'd like library maintainers to add their goals for the 1.33.0 release to the checklist on the Wiki. This will give us all an indication of our progress toward the feature set we want for this release. A few weeks before the release, we'll freeze the feature set, bump the remaing list to 1.34.0, and work on portability and stability until we get it right. The checklist is here: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?1.33.0_Check… Depending on the size of the list, we'll decide when to feature freeze. I'll be travelling for the next week, but will try to answer e-mail as I find time. Doug

18 63

Re: Asynchronicity (long)
by Don G 02 Apr '05

02 Apr '05

Hi Maxim, Thanks for the pointer to libevent; it is interesting. Please find my reply below. --- Maxim Yegorushkin <e-maxim(a)yandex.ru> wrote: > Iain Hanson wrote: > >>> On Fri, 2005-04-01 at 19:57 +0400, Maxim Yegorushkin wrote: >>> >>> By the way, we use libevent and are happy with it. It's >>> portable (Linux/Windows) and has very simple interface. I >>> just don't see a need for the stuff you guys are >>> discussing here. >> >> Because we like our libraries spelt in C++ :-). > > So do I. > > Nevertheless, I like to keep simple things simple. I don't > feel like I need a glue layer over simple socket and epoll > api's. epoll() is not available on even all Unix systems, let alone with Windows sockets. AFAIK, the only multi-wait method on Windows is select(). That said, I don't find select/poll/epoll et.al. very pleasant and would like to see them hidden completely. Manual mantenance of structures and bit flags is not my idea of fun, and for the novice to intermediate level developer this can be a frustrating and error prone experience. Obviously, this is a bit of a subjective matter, but the C nature of these API's makes them less than ideal for a C++ bigot such as myself ;) > What I might need is an event demultiplexor. Heavy loaded > servers I'm working on are event driven. Each event which > is not naturally a file descriptor readiness change is > transformed in a socket(pair) write, so that it can be > demultiplexed by epoll_wait(). Thus, an application just > handles events in a loop around epoll_wait(). So, I might > need a little syntactic sugar around this stuff, but I have > not elaborated my generic implementation yet. This is exactly the kind of thing a general async library would solve for you. When something is done, instead of calling send/write on a socket that exists solely to make epoll happy, just queue the C++ call (i.e., a boost::function<> object). Best, Don __________________________________ Do you Yahoo!? Make Yahoo! your home page http://www.yahoo.com/r/hs

2 2

Re: Asynchronicity (long)
by Don G 02 Apr '05

02 Apr '05

Hi Boris, > Hi Don, > > maybe we should go through an example - then I hopefully > understand better. :) Sounds good... > Let's say we have a function void block(). We call this > function and we don't know when it will return. Now we want > to use an asynchronicity library to call this function > asynchronously. If we had a library similar to how .NET > supports asynchronicity code would basically look like > this: > > AsyncDelegate dlgt = new AsyncDelegate(block); > dlgt.BeginInvoke(new AsyncCallback(callme)); > > There is a magic class AsyncDelegate which calls block() > in a thread. When block() returns in the thread callme() > is executed which is our callback function. If we forget > about the class AsyncCallback for a moment I think the > asynchronous support in .NET is pretty simple and easy to > understand. > How would you call block() asynchronously with your nexus > and channel class? What is the difference? And what is > the advantage of your design which introduces two classes > whose meaning is difficult to grasp in the beginning? The answer to a good part of this is a question<g>: since C++ is not garbage collected, how should we deal with the case when the object to which "callme" belongs gets deleted while we are waiting for block() to return? Once "dlgt.BeginInvoke()" in your example is called, we have a dependency on the target "callme" that must be managed somehow. This is the purpose of the channel class I proposed. That being said, I've never created a facility quite like the example, so I will give it more thought and get back to you. > Regarding asynchronous I/O: If we had an asynchronicity > library which could call any blocking function > asynchronously it would do so by using threads. Yes, but that is not what I was proposing :) The pseudo code I posted was focused on the event queue, enqueue, dispatch and cancel. There was nothing about making time via worker threads. The example you showed could be changed slightly to queue a call to callme to be delivered on the same thread that called BeginInvoke (assuming it was cooperative). > However if the asynchronicity library knew that a > function blocks because of I/O it maybe would use a > better > implementation like overlapped I/O. This > could be a reason *not* to build a network library > upon a general purpose asynchronicity library. True if your original example was the only facility provided by that library. Other means should be used by the network library to deal with I/O completion. > In Linux eg. it might be better to use the new epoll() > function (new in Linux 2.6) to simulate asynchronous > I/O instead of creating, managing and blocking in > uncountable threads. Indeed. > In .NET the socket class has a method BeginAccept(). > While there is no difference for the application > programmer between this method and calling any other > method asynchronously the .NET framework knows that > BeginAccept() does I/O and will not create a new > thread but do overlapped I/O instead. A network > library with support of asynchronous I/O must then > not be built upon a C++ asynchronicity library but must > provide the same "look and feel" to an application > programmer - asynchronicity looks everywhere the same > but might be implemented differently in the network > library for a better performance. Yes. I agree. > Last but not least after thinking so much about > asynchronicity: Isn't an asynchronicity library not > just another interface for Boost.Thread? Instead > of managing threads yourself you just tell the > library to call a function in a thread and then call > back. Again, making time was not the goal of the technique I was proposing. It was about the mechanics (of hopefully the "classical" and the quantum kind<g>) of event queues based on boost::function<>. > An asynchronicity library should then be tightly > connected to Boost.Thread - it isn't a stand-alone > library at all? The facility you described above could be a convenient wrapper around inconvenient functions that block. This would be much better than hand coding such a thing, but would hopefully not be something that one had to use often. It raises too many issues for the non-garbage-collected land in which we live (out parameters and what not). Best, Don __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

1 0

[Format] Failures on sunpro-5_3
by Doug Gregor 01 Apr '05

01 Apr '05

All of the Boost.Format tests are failing on SunPro 5.3 with this error: "/home/nbde52d/src/boost-regression/boost/boost/format/ alt_sstream_impl.hpp", line 248: Error: Cannot assign void* to char*. Can this be solved, or should we mark this compiler as unusable for the Format lib? Doug

2 1

Re: [boost] Re: Re: Asynchronicity (long)
by Iain Hanson 01 Apr '05

01 Apr '05

On Fri, 2005-04-01 at 19:57 +0400, Maxim Yegorushkin wrote: > By the way, we use libevent and are happy with it. It's portable > (Linux/Windows) and has very simple interface. I just don't see a need for > the stuff you guys are discussing here. > Because we like our libraries spelt in C++ :-). /ikh

2 1

Classpath to C++ conversion
by Tushar 01 Apr '05

01 Apr '05

Hi all, I am thinking of converting GNU Classpath used for GCJ to C++. I have following reasons about why to do this. 1. C++ requires a Good OOPs library with well defined api. Java has that . While C++ also have many of them, most do not look truly object oriented. As all of us know, Java is really a subset of C++ from pure language point of view. C++ has every thin that JAVA has except GC. But still programming in JAVA is more easy because they have a well define API to work with. I thinks, we should have some thing similar in C++ also. 2.C++ has much of the libs using STL. The only problem is STL is not a object oriented.(See STL Tutorial and reference) This really makes it difficult to think in OO and implement in STL. Particularly in STL, T a,b T a=b means a is separate entity and same for b. This make problem in many case where one wants just pointer e.g File handling and manipulation of large buffer. 3.There are other "standard" API to work with things like thread and networking. I know many libs are there on this boost and some other good site, but there is no uniform framework to work with in C++,one like one JAVA provides. These was some reasons why C++ libs are required. My idea is that API specification is already defined for java. And it seems much complete.I mean to say more complete then if start deciding from scratch -:). Why not to use java then? 1.JAVA is not free neither under GPL. 2.GC makes problem for many programs. 3.Compilation of java to binary using GCJ or something similar gives performance problem 4.After all, many C++ programmer like me do not want to change language but I do want a good uniform library. Difference bet proposed C++ and Java 1.Everything is a pointer other them simple atomic data types.(Same) 2.There is no GC. Its here large change will be required. (Diff) 3.Arrays - I do not know. Should it be made object like in java or let it be as it is in C++. Later seems good and one can use some class like Array to have similar effects.(?) 4.Every thing is subclass of Object(Same). 5.Sync support in Object (i.e to every object) using wait and signal - I am not sure. This makes it easy but may also bring some performace problem (?) Ok, enough thinking. Now implementation. Here I am thinking of converting entire GNU Classpath to C++. One major change will be lack of GC. For others, I will have to dig deeper. For GNU Classpath people, it will be review of their code. Regards, Tushar

10 24

Re: [boost] Re: Asynchronicity (long)
by Iain Hanson 01 Apr '05

01 Apr '05

On Fri, 2005-04-01 at 09:14 -0500, Edward Diener wrote: > Boris wrote: > 1) No one normally uses 1000 sockets. Be real rather than hyperbolic if you > are trying to make a point. Sorry, but that is a bad assumption. A server that I'm currently working on will have 1,000's of sockets open concurrently. Application gateways, web servers and database connection concentrators are typical of Apps that often need large numbers of sockets. /ikh

2 1

Re: [boost] Re: Re: Asynchronicity (long)
by Iain Hanson 01 Apr '05

01 Apr '05

On Fri, 2005-04-01 at 18:02 +0300, Boris wrote: > Iain Hanson wrote: > > On Fri, 2005-04-01 at 13:53 +0300, Boris wrote: [snip] > I don't think our opinions are very different. You agree that library users > should have some control about the implementation for a better performance. yep! > There is really a trade-off between design and performance. As we have seen > in another thread today's operating systems don't support asynchronous I/O > very well. They don't need to as long as they support threading. > In Linux asynchronous I/O would be probably best implemented > using epoll() as multiplexing is the traditional *unix way. No. The unix way is to have as many orthogonal ways of doing something as possible ;-). Because the user knows best what works well on their platform they should probably be able to select the implementation whether it uses epoll, user space threads, or kernel supported aio. > A C++ network > library which can't support efficient I/O because of its design won't be of > much use. It could be perfectly designed but it couldn't be implemented > using best available I/O APIs on different operating systems. > I don't understand what your trying to get at here. There are sufficient mechanisms to does this on all the major platforms. It is just that they happen to vary by platform. /ikh

1 0

Re: [boost] Re: Asynchronicity (long)
by Iain Hanson 01 Apr '05

01 Apr '05

On Fri, 2005-04-01 at 13:53 +0300, Boris wrote: > While asynchronicity in .NET is basically based on threads it is not true > for asynchronous I/O. If you built asynchronous I/O on top of an > asynchronicity library with callbacks in threads you will end up with 1000 > threads blocked in read() if you have 1000 sockets. No. This would be a configuration or implementation detail. The only requirement is that you have at least 1 thread dispatching async requests and queueing work to be dispatched. LibC AIO has an init function where the user can supply a hint regarding size of thread pool to use. I think the contract for a C++ lib should be stronger and allow the user to specify/control the size of the thread pool as well as the type of the ACT ( not just callback, but signal and polling ). /ikh

2 1

[format] conversion to string
by Vladimir Prus 01 Apr '05

01 Apr '05

Hello! While it's generally considered a bad practice to provide implicit conversions, I think it would be good to provide such a conversion for the boost::format class. Currently, I can't write: string s; s = format("%1%") % 10; and need to write s = (format("%1%") % 10).str(); Maybe it's specifics of my code, but I can count 10 such conversions in a single source file. I think that: 1. Calling .str() is rather inconvenient. 2. The 'format' class most often used inside expressions. It's not likely to be passed around to functions and so the dangers of implicit conversions are not critical. Thoughts? - Volodya

4 7