- Boost - lists.boost.org

Re: [boost] Re: Re: Network library: What we have until now
by Iain Hanson 14 Apr '05

14 Apr '05

On Thu, 2005-04-14 at 16:46 +0400, Maxim Yegorushkin wrote: > On Thu, 14 Apr 2005 13:07:42 +0100, Iain Hanson > <Iain.Hanson(a)videonetworks.com> wrote: > > Probably you mean Protocol Data Units (PDU) - the messages a protocol > communicates with? It would be unwieldy to you specify and execute timouts > using spirit grammar, I guess :) Yep. I meant the packet layout not behaviour. Whose been taught or playing with OSI ;-). They only use PDU in OSI. In ip land we say packet. /ikh

1 0

Re: Network library: What we have until now
by Don G 14 Apr '05

14 Apr '05

Hi Iain, > Not all platforms have threads. There may even be > some that don't supply co-operative multi-tasking. I'm sure they exist. Can we name any that are important to this design? > Non-blocking calls are akin to polling. > A non-blocking read fails if there is no data to > read. A non-blocking write fails if there is > insufficient space in the queue. If a non-block > write succeeds then its behaviour is identical > to a blocking write. > > An async write queues the request and success or > failure is reported sometime later. At issue here, for me<g>, is that the grouping of objects to select/whatever calls is non-portable. In other words, the select_set class must do many silly things on some platforms to support a bad mixture or too many. So, in my proposal, this is in the realm of internals. > BTW callbacks are just *one* way that async > completion can be reported. Agreed. But don't we have to pick something? ;) Best, Don __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

1 0

[date_time] USE_DATE_TIME_PRE_1_33_FACET_IO
by Vladimir Prus 14 Apr '05

14 Apr '05

While comparing regression tests results for Boost.Build V1 and V2, I noted that some date_time tests fail, and traced this to the fact that V2 does not define USE_DATA_TIME_PRE_1_33_FACET_IO while compiling the tests. So, I have a couple of questions: 1. What does the macro do? I could not find anything in the docs. 2. For V2, I have as much as three choices: - Add this define to the same sets of tests and in V1 Jamfile - Add this define to "project requirements" for the date_time/test Jamfile.v2, so it will be applied to all targets - Add this define to "usage requirements" for the date_time library, so that any executable files linking to date_time will get this define set. Which option is the best? Thanks, Volodya

2 1

Re: Network library: What we have until now
by Don G 14 Apr '05

14 Apr '05

Hi Caleb, --- Caleb Epstein wrote: > On 4/13/05, Don G <dongryphon(a)yahoo.com> wrote: >> I also believe that non-blocking is an I/O only thing; it is not >> needed for connect or accept. > > Not sure about the need for a non-blocking accept, but a > non-blocking connect is a must-have. What do you mean by non-blocking exactly? Based on the proposal I posted, async connect seems about the same as non-blocking: call me when I can connect... oh, wait, I am connected :). Maybe I'm missing something in the definitions? Best, Don __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail

2 1

Re: [boost] Re: Network library: What we have until now
by Iain Hanson 14 Apr '05

14 Apr '05

On Thu, 2005-04-14 at 11:29 +0400, Maxim Yegorushkin wrote: > On Tue, 12 Apr 2005 21:39:24 -0700 (PDT), Don G <dongryphon(a)yahoo.com> > wrote: > Was not Mac OS Classic been buried long ago? People on this thread are still discussing Win95 :-(. > > IMO, sockets are abstractions out of the scope of any language. Their > interfaces can be implemented using any general purpose programming > language, but still you'll have to call an underlying OS C API. That's a > fact of life and I don't think this is bad - C is the most portable > programming language ever. Yes. But, that is not necessarily the 'C' socket lib :-). An optimal ( but not very portable ) implementation would replace the 'C' socket lib. > Here is my two philosophy cents. > > You propose another set of concepts over socket concepts just to > send/receive a bunch of mere bytes. Geez, another glue layer over sockets > that adds nothing but syntax sugar. Aren't we already tired of software > bloated from glue layers over glue layers over...? You don't just send > bytes, rather you execute protocols. Sockets have the right implementation > level and complexity to build *efficient* protocols upon. I agree with you. I think the well defined concepts developed from BSD sockets and well known by many programmers is what we need for a layer 1 sockets lib. And I've always liked the idea of being able to specify protocols as a Spirit grammar. > Protocol is the > only glue layer you really always need, the layer that binds your > application logic with network transport layer (sockets) providing the [snip] ^^^^^^^^ and Network and Data Link Layers. /ikh

2 1

Re: async socket i/o [long]
by Don G 14 Apr '05

14 Apr '05

Hi Scott, When I implemented this at work, the sync stuff did indeed rely on the internal async mechanism. It turned out "better" not to pass function objects about for the synchronous case, though it would work. So, I guess it is partly a performance thing as well as a convenience thing to allow mixing sync/async without mixing layers. The async flow (aka, "function queue") is something I would like to revisit soon. A key concept of my proposal (which I should post to the sandbox) is cancel. This complicates the use case, but I don't see a way out of it. Best, Don --- Scott Woods wrote: > > Hi Don and Michel, > > > ----- Original Message ----- > From: "Don G" > To: <boost(a)lists.boost.org> > Sent: Thursday, April 14, 2005 4:07 PM > Subject: [boost] Re: async socket i/o [long] > > > > Hi Michel, > > > > > Ok the reason I expose it is for the possibility > > > to write single threaded reactive servers. > > > > I have written such using the library I proposed. The missing > > ingredient is a function queue mechanism. I posted one to the > list a > > couple weeks ago, but feel that it is not technically a > networking > > thing. Of course, the network layer could be coupled to it in > some > > key places which would make things simpler to use. > > > > [snip long useful text] > > I agree and nicely written :-) At least that stuff feels better. I > have to > admit > I'm still tangled up with the broader scope. Wondered if this might > clarify > things; > > [4] boost > --|-------------------serialization-------------------------| > [3] boost --|-----------|---------------|- sync file --|-- sync > socket -| > [2] boost --|-----------|---------------|- async file -|- async > socket -|-------------- > [1] boost --|- sync file -|- sync socket > -|-----------------------------|- > async flow - > [0] system -|- sync file -|- sync socket -|- async file -|- async > socket -|- > async flow - > > Level [0] shows the platform APIs. The repeated names at levels [1] > and [2] > are the > Boost interface to the same names at system level; the boost > versions are > platform > independent. The boost async libraries for file and socket I/O are > bumped up > to > level [2] to highlight the need for a generic "async flow" library. > A means > of passing > control from one dis-joint code fragment to another. > > Sync file and sync socket appear again on level [3] as that > behaviour may be > re-implemented over the async level. > > Serialization is shown at the top for obvious reasons. > > I suppose for any given platform there may be holes, e.g. an old > MacOS may > not > support async file. According to this diagram at least, sync file > and sync > socket are > optionally implementable as either a layer over the platform API or > as > something > that makes use of the boost async file and async socket. > > While this might be all a bit pie-in-the-sky, if sync file and sync > socket > can be > implemented over a platform independent interface, the only time > you wouldnt > do so would be when the platform has no async support? Or for > absolute best > speed as you described in your text? __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

1 0

[hash] Built in arrays
by Daniel James 14 Apr '05

14 Apr '05

I've just checked in an attempt at supporting built-in arrays in boost::hash. It's not great and I might remove it before Friday. My main problem was that overloading hash_value for both T* and T[Size] causes ambiguity - so I implemented it using partial specialization of call_hash. (If anyone knows how to correctly implement the overload, preferably without SFINAE, let me know, although I'll spend some time looking into it if I can find the time). So I implemented it using partial specialization of hash_detail::call_hash. This breaks the specification of boost::hash_combine, which is specified in terms of boost::hash_value - but boost::hash_value is not overloaded for built in arrays. So it might be a good idea to change it so that it's specified in terms of boost::hash. In a way, I prefer this, since users should never really call hash_value directly and I think the documentation should reinforce this. Any thoughts Peter? Daniel

4 14

boost(1.32.0) date_time libraries with stlport4.6.2..single threaded libraries not generated..
by Manish Mangal 14 Apr '05

14 Apr '05

Hi I am trying to create the boost libraries with toolset vc-7_1-stlport. STLPort 4.6.2 has been installed Successfully and runs fine on the system ( VC .Net2003 C++7.1). The problem is that only the multi-threaded libaries are being created. The single threaded (dynamic and static) are not being genereated. I also read on earlier posts a few problems with wchar_t. So I modified the vc71.mak file of STLPort4.6.2 to add /Zc:wchar_t and then recompiled STLPort. I also changed the Vc-7_1-stlport-tools.jam file to look like #feature native-wchar_t : off on ; feature native-wchar_t : on off ; Since the Multi-threaded libraries are being built, I assume I do not have the wchar_t problem. The bjam command I use is: bjam "-sTOOLS=vc-7_1-stlport" "-sSTLPORT_VERSION=4.6.2" "-sSTLPORT_4.6.2_PATH=C:\SourceLibrary\STLport-4.6.2" "-sBUILD=debug release <runtime-link>static/dynamic <threading>single/multi <stlport-iostream>on <native-wchar_t>on" install On one of the boost.regex pages it is written : Note that the full STLPort libraries appear not to support single-thread static builds.... If it is not possible to create single threaded static builds then how to use the boost multi-threaded date_time libraries with the STLport libraries??? Any help is much appreciated. Manish Mangal Stratagen Systems 1-425.821.8454 ext. 136

2 1

Re: [boost] status of circular buffer
by Jan Gaspar 14 Apr '05

14 Apr '05

Hi Vincent, I'm working on it and I'd like the circular buffer to be included in the next version but unfortunatelly I don't have a lot of spare time. You can see the progress in the sand-box cvs. Btw. when is the branching for release scheduled? I can then say yes or no. Jan --- Vincent Torri <Vincent.Torri(a)iecn.u-nancy.fr> wrote: > > Hello, > > I would like to know what is the status of circular > buffer, in particular > if there is a chance that it will be included in the > next version of > boost. > > Thank you > > Vincent Torri > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > Send instant messages to your online friends http://uk.messenger.yahoo.com

1 0

Re: [boost] Re: Network library: What we have until now
by Iain Hanson 14 Apr '05

14 Apr '05

On Wed, 2005-04-13 at 20:14 -0700, Don G wrote: > I think this presupposes a mostly manual association of > selectable_object with select_set? The select_set is then used to > wait? Yes. > If not, please explain the importance of "when can non-blocking > operations proceed" vs. "async operations are done". If the > "operation is done" callback occurs by calling dequeuing a > boost::function<> then the app is still "single threaded" to the > user. Not all platforms have threads. There may even be some that don't supply co-operative multi-tasking. Non-blocking calls are akin to polling. A non-blocking read fails if there is no data to read. A non-blocking write fails if there is insufficient space in the queue. If a non-block write succeeds then its behaviour is identical to a blocking write. An async write queues the request and success or failure is reported sometime later. BTW callbacks are just *one* way that async completion can be reported. /ikh

1 0