- Boost - lists.boost.org

Re: [network] An RFC posted to the sandbox
by Don G 15 Apr '05

15 Apr '05

Hi Boris, > I agree with you that URLs and alike belong to a > higher level. Level 0 will ultimately depend on > C APIs like Berkeley sockets. Concepts like URLs > will be implemented in a higher level based on > whatever we have in level 0. The stuff I proposed would be level > 0. Internally I had two levels beneath it. The lowest was a Socket class (for platforms that had sockets; not Mac OS 9). The level above Socket was very much like Michel's proposal, minus some of the virtuals. :) For addresses, there was a two step process to convert from host names to sockaddr's. The first was to resolve the host name (via a platform specific means). The second was to resolve the port/scheme_name. In the end, net::address was responsible for coordinating the async address resolution process and converting text components from the URL to a sockaddr (again, where sockaddr was the target). To users above the layer I proposed, nothing else much fits other than a textual form. For that, I believe a URL is the right answer. Best, Don __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

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

15 Apr '05

Hi Iain, On Thu, 2005-04-14 at 06:43 -0700, Don G wrote: > 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? > > I don't know which specifically but it will probably > be the RTOS'es such as PSOS, VxWorks, maybe QNX, and > Symbian plus maybe others. You mean an RTOS doesn't support threads? ;) Seriously, though, would someone with network experience on these systems care to speak up...? >> 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. > > Platform select may not be completely portable but > the concept is supported across most if not all > platforms that I am aware of. Therefore, it is not > hard to abstract a standard set of behaviour for > C++ and leave the Lib implementation to deal with > the differences. Ace call the the Reactor. This approach still leaves the user with the manual bookkeeping to perform, and I'm not seeing why. Is it just to avoid threads? >>> BTW callbacks are just *one* way that async >>> completion can be reported. >> >> Agreed. But don't we have to pick something? ;) > > Why? aio supports polling, callbacks, and signals. > Different users have differing needs and a good Lib > will support the different patterns. So you agree - we have to pick something. ;) Your something sounds like multiple techniques, but it is still something that must be chosen. In my proposal there is: blocking, async w/callback, non-blocking w/callback, and polling (via non-blocking w/o callback). Signals are platform-specific (and scary<g>), so I didn't include them. For sake of discussion, let's just say we support 5 different methods. It sounds like an SSL implementation of a net::stream would have to support them all as well? What about higher level libraries? Following this reasoning, it would seem that all levels of networking must support all styles of completion detection/notification. Perhaps this straw man is inaccurate, but if it is accurate (and I think that it is), I can see why Boost has no net library. And even if it did, who in their right mind would want to write layers on top<g>? It would be way too complex. My philosophy on this is simple (if indeed anything in this space can carry that moniker<g>): what is the problem? I think it is achieving concurrent operations with portable/safe/efficient notification of completion. I think a small number of operation modes (see my proposal) is more than adequate to achieve this end. The fewer modes, IMHO, the better. If threads or their facsimile are not portable enough, I think some minor adjustments to my proposal might work. I would like to hear from someone familiar with a system that has nothing remotely like threads before carrying out this particular thought exercise. ;) Best, Don __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

1 0

[1.33.0] Delay freeze until Friday, April 22
by Douglas Gregor 14 Apr '05

14 Apr '05

I had originally intended to feature-freeze tomorrow, but instead we're going to wait one extra week. We have 611 regressions and ~2700 new failures on the main trunk. Let's see if we can get that number down a bit :) Thanks, Doug

2 3

[optional] self-assignment and assignment of references
by Fernando Cacciola 14 Apr '05

14 Apr '05

Please, see and possible comment on my recent post titled [optional] self-assignment and assignment of references in the users list TIA Fernando Cacciola

1 0

[shared_ptr] possible bug in sp_counted_base_cw_ppc.hpp
by Joaquín Mª López Muñoz 14 Apr '05

14 Apr '05

I think that the functions atomic_increment atomic_decrement atomic_conditional_increment should be marked as inline, as they are defined in a header file. This is causing multiple definition problems, see for instance http://tinyurl.com/6eub2 Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 27

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 06:43 -0700, Don G wrote: > 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? I don't know which specifically but it will probably be the RTOS'es such as PSOS, VxWorks, maybe QNX, and Symbian plus maybe others. > 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. Platform select may not be completely portable but the concept is supported across most if not all platforms that I am aware of. Therefore, it is not hard to abstract a standard set of behaviour for C++ and leave the Lib implementation to deal with the differences. Ace call the the Reactor. > > > BTW callbacks are just *one* way that async > > completion can be reported. > > Agreed. But don't we have to pick something? ;) Why? aio supports polling, callbacks, and signals. Different users have differing needs and a good Lib will support the different patterns. /ikh

1 0

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