"Thorsten Ottosen" <nesotto@cs.aau.dk> wrote in message news:de2lb2$d6u$1@sea.gmane.org...

"Christopher Kohlhoff" <chris@kohlhoff.com> wrote in message

5. can't socket.recv() use something more highlevel than void* and size_t arguments? Why not std::vector<char> ? (The same applies to all the interface functions)

Furthermore, if you do want array arguments, then you might just say template< class T, std:size_t N > void receive( T (&array)[N] ) { /* call void ptr version here */ } or perhaps just template< std::size_t N > void receive( char (&array)[N] ) { ... } br Thorsten

"Jeremy Maitin-Shepard" <jbms@cmu.edu> wrote in message news:87iry3c9cn.fsf@jbms.ath.cx...

"Thorsten Ottosen" <nesotto@cs.aau.dk> writes:

...

"Thorsten Ottosen" <nesotto@cs.aau.dk> wrote in message news:de2lb2$d6u$1@sea.gmane.org...

...

"Christopher Kohlhoff" <chris@kohlhoff.com> wrote in message

...

...

5. can't socket.recv() use something more highlevel than void* and size_t arguments? Why not std::vector<char> ? (The same applies to all the interface functions)

std::vector<char> (even with additional offset and length parameters) introduces significant overhead for users that do not otherwise have any reason to use std::vector. I do not think the additional safety provided is worth the cost of this overhead.

doesn't the overhead depend on the amount of data sent?

...

Furthermore, if you do want array arguments, then you might just say

...

template< class T, std:size_t N > void receive( T (&array)[N] ) { /* call void ptr version here */ }

...

or perhaps just

...

template< std::size_t N > void receive( char (&array)[N] ) { ... }

Requiring that the size be known at compile-time, and that an actual static-sized array be used in order to call the receive function, is definitely not a good idea.

Then why do all the examples work on statically sized arrays? If we're not working on statically sized arrays, then why not use vector? I'm not convinced about any overhead noticable associated wirh vector. Besides, both versions could be provided. -Thorsten

David Abrahams <dave@boost-consulting.com> writes:

"Thorsten Ottosen" <nesotto@cs.aau.dk> writes:

...

Then why do all the examples work on statically sized arrays?

If we're not working on statically sized arrays, then why not use vector?

I'm not convinced about any overhead noticable associated wirh vector.

Besides, both versions could be provided.

Why not just provide a standard iterator interface so that you can write to anything you like?

All operating systems with which I am familiar only support reading and writing from memory ranges. Thus, if the iterators are actually pointers, this can be implemented efficiently. If they are not pointers, though, a temporary buffer will have to be allocated, the actual read performed using this temporary buffer, and then the data copied to the output iterator provided by the user. Because of this inefficiency, I doubt anyone would actually use the iterator interface with non-pointers. -- Jeremy Maitin-Shepard

"Thorsten Ottosen" <nesotto@cs.aau.dk> writes:

"Jeremy Maitin-Shepard" <jbms@cmu.edu> wrote in message news:87iry3c9cn.fsf@jbms.ath.cx... [snip]

...

std::vector<char> (even with additional offset and length parameters) introduces significant overhead for users that do not otherwise have any reason to use std::vector. I do not think the additional safety provided is worth the cost of this overhead.

doesn't the overhead depend on the amount of data sent?

I suppose that is true. If a vector must be passed to the receive function, then programs using this library will either have to use an std::vector for any buffers used for receive, which is annoying for users that would prefer to use a different data structure for a buffer, and has the additional overhead of a dynamically allocated buffer and the additional storage std::vector requires for the size, capacity, etc. Alternatively, the user could create an std::vector just for each receive call, then copy the data out after it completes. In either case, though, although the additional cost may be rather small compared to the cost of network I/O, it is an additional cost which provides only some additional safety, while introducing a more complex and less generic interface. The ideal interface would be an output iterator and a size, but this cannot be used efficiently; an arbitrary memory range seems like the next most generic interface, and this is also precisely the interface supported by operating systems. [snip]

...

Requiring that the size be known at compile-time, and that an actual static-sized array be used in order to call the receive function, is definitely not a good idea.

Then why do all the examples work on statically sized arrays?

Well, there aren't many examples, and I didn't write them in any case ;) I'll admit it is a common network I/O paradigm to read into (large) fixed-size buffers, but there are certainly other usage patterns (such as reading a fixed-size ``packet'' length specification, and then after ensuring that the buffer is large enough, reading the entire ``packet'' of the specified length with a single read/recv call. Furthermore, even a fixed-size buffer that is used might have its size specified at runtime.

If we're not working on statically sized arrays, then why not use vector?

There are many possible reasons, but the point is, there is no reason to force the user to use vector, when doing so provides no real benefit.

I'm not convinced about any overhead noticable associated wirh vector.

Besides, both versions could be provided.

Well, I think the critical version to provide would be the memory range version (which already exists). The other two versions could be provided, but the std::vector version, which would be implemented as a very simple wrapper around the memory range version, would only be slightly more convenient than using the memory range version directly, and the static array version would probably not be used much at all, because it is often useful to read into only a portion of an array, rather than always reading into the entire array. As a side note, perhaps the names read and write should be used rather than send and receive/recv if the library will at some point support I/O on non-sockets, such as pipes and fifos. -- Jeremy Maitin-Shepard

"Thorsten Ottosen" <nesotto@cs.aau.dk> writes:

"Jeremy Maitin-Shepard" <jbms@cmu.edu> wrote in message news:87acjedijx.fsf@jbms.ath.cx...

...

"Thorsten Ottosen" <nesotto@cs.aau.dk> writes:

...

...

reason to use std::vector. I do not think the additional safety provided is worth the cost of this overhead.

...

doesn't the overhead depend on the amount of data sent?

I suppose that is true. If a vector must be passed to the receive function, then programs using this library will either have to use an std::vector for any buffers used for receive, which is annoying for users that would prefer to use a different data structure for a buffer, and has the additional overhead of a dynamically allocated buffer and the additional storage std::vecetor requires for the size, capacity, etc.

the space required by vector is 3 words. that is not much for many purposes.

Well, I agree it is not a large amount of overhead given certain usage patterns. But note that requiring either a vector or a static array prevents reading directly into a memory-mapped region. It is also not nearly as convenient to directly read a structure or non-char type without the memory-range interface.

...

some additional safety, while introducing a more complex and less generic interface.

how is passing 1 agument instead of two going to be more complex? is it because you can't get the size wrong? :-)

Well, more complex in the sense that the operation itself just needs a memory range, but with this interface you can't just pass it a memory range, but rather must pass it something that consists of more than just a memory range. I suppose complex is not a great term to use. [snip]

right. so by passing char (&)[N] you can check that the size argument is not too big. with void* you're just lost.

Well, I admit this safety is rather handy, but I doubt this interface would be used much, since it is not very common to pass arrays around as a reference to static-sized array, so even if the user has a static-sized array, it might not be of the appropriate type at the point where receive/read is called. -- Jeremy Maitin-Shepard

Hi Stefan, --- Stefan Arentz <stefan.arentz@norad.org> wrote:

Or you could get the first 10 bytes in a new buffer and then 'compress' the original buffer. That way you can have sort of a ring buffer where you can take stuff of the beginning when you have received a full packet.

asio has the fixed_buffer template which does a similar sort of thing. It is used to implement the buffered_* templates that add buffering to sockets while retaining the interface.

Always when I use asio, I end up implementing something similar in my

code It would be nice if it were part of the standard asio library.

http://en.wikipedia.org/wiki/Java.nio#NIO_buffers

(Not saying that we should copy this, I'm just saying that it is good

functionality to have in a frmework that does network io)

Would you be able to share the C++ interface you have in mind for this? Cheers, Chris

--- Jeremy Maitin-Shepard <jbms@cmu.edu> wrote:

As a side note, perhaps the names read and write should be used rather than send and receive/recv if the library will at some point support I/O on non-sockets, such as pipes and fifos.

Yes, I agree that read and write are better, because of the "portability" of the names to non-sockets that it gives. I've wanted to make that change for some time, but the thing that has been preventing me is what to call the datagram functions sendto and recvfrom, as writeto and readfrom don't seem quite right. Any suggestions? Cheers, Chris

--- Jeremy Maitin-Shepard <jbms@cmu.edu> wrote:

Well, one possibility is to just use the names `read' and `write'. If necessary, these functions can be distinguished from the connected-socket versions by the extra parameter. Alternatively, you could use the names `unconnected_read' and `unconnected_write'.

After pondering this for a while, I think what i'm going to do is: - Rename the Sync_Recv_Stream concept to Sync_Read_Stream, and change it's recv() to be read(). - Rename the Sync_Send_Stream concept to Sync_Write_Stream, and change it's send() to be write(). - Rename the Async_Recv_Stream concept to Async_Read_Stream, and change it's async_recv() to be async_read(). - Rename the Async_Send_Stream concept to Async_Write_Stream, and change it's async_send() to by async_write(). - The free functions asio::send*, asio::async_send*, asio::recv* and asio::async_recv* will be renamed to use write and read. - Add new send and receive functions to the stream_socket which also allow "flags" to be passed (something missing at the moment). - Rename dgram_socket's functions sendto to send_to, async_sendto to async_send_to, recvfrom to receive_from, and async_recvfrom to async_receive_from. These functions will also be changed to allow the flags to be passed. - Rename dgram_socket to datagram_socket. These concepts and the stream_socket class will then mirror the way sockets and other resources can be used on UNIX systems (where you can call read() or write() on a socket just as with a file, or recv() and send() if you need to pass flags). Cheers, Chris

Hi Thorsten, --- Thorsten Ottosen <nesotto@cs.aau.dk> wrote:

1. I hate cryptic short names like

dgram_socket. recv

why not write datagram and receive? (the other short names seems ok and quite standard)

Ok, fair enough :)

Looking at the Daytime1 example, I wounder why

2. asio::ipv4::host host; host_resolver.get_host_by_name(host, argv[1]);

is not written

asio::ipv4::host host = host_resolver.host_by_name(argv[1]);

Basically for consistency with the rest of the library, in particular: - Consistency with a future asynchronous version of the same function. As a rule, in async versions of the functions complex structures or buffers need to be passed as arguments, andthe only difference between the sync and async functions is the callback handler, i.e.: void operation(parameters); template <typename Handler> void async_operation(parameters, Handler handler); - Consistency with other functions that take a complex structure argument (where those functions might need to be member templates and deduce the argument type, e.g. socket.get_local_endpoint).

3. why is everything public in a host?

Only because the host represented data without behaviour, but if a class with member functions is preferred I can do it that way.

4. why does both the stream_socket and the socket_connector need to know about the demuxer? Can't the socket_connector ask the stream_socket for its demuxer (I want to simplify usage if possible)

This may be moot if asio is changed to use connect/async_connect functions on the socket itself. What do you think of that change? However I originally had it this way so that you can have a pool of demuxers (e.g. one demuxer per CPU) and "load balance" your objects across them. So you might have one demuxer where all connections are performed, but once the connection is established the socket is run on a different demuxer.

5. can't socket.recv() use something more highlevel than void* and size_t arguments? Why not std::vector<char> ? (The same applies to all the interface functions)

As others have commented, vector<char> can introduce a performance hit due to default construction of the elements. Also, some applications need to send data structures directly, to avoid additional copies. So I'd prefer to keep the operations on the socket class itself using void*. However, IMHO the place for supporting high level types is in non-member functions like asio::send and asio::recv. E.g. template <typename SyncStream, typename InputIterator, typename Handler> size_t send_range( SyncStream& s, InputIterator begin, InputIterator end, size_t* total_bytes_sent = 0); template <typename AsyncStream, typename InputIterator, typename Handler> void async_send_range( AsyncStream& s, InputIterator begin, InputIterator end, Handler handler); I believe that it's in these sorts of functions that asio offers the most extensibility. Would it be useful to add functions like this to the library itself, and what form should they take? Cheers, Chris

Hi Thorsten, --- Thorsten Ottosen <nesotto@cs.aau.dk> wrote:

please consider the other mails too. there are too many drawback in void* IMO.

I have seen/used code where a statically allocated data was far slower than putting it on the heap. This wsa not stack-allocated, but static data. So I'm a bit concerned about performance claims.

The performance problems of requiring vector<char> or char[N] exist on several levels: - For vector<char>, there is the initialisation of the chars to 0 on construction or when you do a resize. Note that this is proportional to the size of the vector, not necessarily to the amount of data transferred. I have seen this have a noticable cost in a CPU-bound server handling thousands of connections. - Requiring a copy from a native data structure into vector<char> or char[N]. If I have an array of a doubles say, I should be able to send it as-is to a peer that has identical architecture and compiler. Avoiding unnecessary data copying is a vital part of implementing high performance protocols. I also believe that the argument that the cost is not significant compared to network I/O does not hold when you are developing an application using asynchronous I/O, since the time spent sending/receiving no longer blocks the application.

If the only performance sensible iterator types are T*, I would't mind simply

template< unsigned N > void receive( char (&)[N] );

template< unsigned N > void receive( char (&)[N], unsigned size );

void recieve( vector<char>& );

void recieve( vector<char>&, unsigned size );

or something.

I just realised that you cannot have such functions on the socket class due to the possibility of a short send or receive. Since you can send or receive fewer bytes than requested, how would you implement something like asio::send_n or asio::recv_n on top of the above functions? Again, I believe that adding safety is best done in layers, in accordance with the don't pay for what you don't need principle: asio::socket::send/recv etc taking void* + size_t. These functions can result in a short send or receive. ^ | asio::send_n/recv_n etc taking void* + size_t. These functions attempt to transfer the all of the requested data. ^ | asio::send_?/recv_? etc. New functions that take safe types like vector<char> and char[N]. Cheers, Chris

From: Christopher Kohlhoff <chris@kohlhoff.com>

...

The performance problems of requiring vector<char> or char[N] exist on several levels:

- For vector<char>, there is the initialisation of the chars to 0 on construction or when you do a resize. Note that this is proportional to the size of the vector, not necessarily to the amount of data transferred. I have seen this have a noticable cost in a CPU-bound server handling thousands of connections.

Don't construct a vector of a given size or use resize(), then. Rely on reserve() instead.

- Requiring a copy from a native data structure into vector<char> or char[N]. If I have an array of a doubles say, I should be able to send it as-is to a peer that has identical architecture and compiler. Avoiding unnecessary data copying is a vital part of implementing high performance protocols.

Agreed. OTOH, using swap(), *if* a user used a vector<double> instead of the array you mention, then vector won't add overhead.

I believe that adding safety is best done in layers, in accordance with the don't pay for what you don't need principle:

asio::socket::send/recv etc taking void* + size_t. These functions can result in a short send or receive. ^ | asio::send_n/recv_n etc taking void* + size_t. These functions attempt to transfer the all of the requested data. ^ | asio::send_?/recv_? etc. New functions that take safe types like vector<char> and char[N].

std::vector takes an allocator template and constructor argument. A suitable allocator type could be constructed to "allocate" from a user-supplied buffer and fail when that buffer is exhausted. The problem here is that the Standard allows all instances of the same type to be considered equivalent, so this won't work. Instead, how about a std::vector-like class that takes a user-defined, fixed-size block of memory? Then, instead of using an allocator, it uses its own memory management class that doles out elements from the fixed, user-supplied memory. Such a class could even avoid the default construction worry altogether by eliminating resize() and making the constructor that takes a number simply reserve that much space. (Deviating that much from std::vector means you wouldn't want to make it too similar, or at least you'd want the name to be quite dissimilar.) Using a user-supplied block of memory means that the memory can come from a stack allocation, static memory, the free store, a memory mapped file, etc. That class cannot be copyable, but it could be movable and swappable. The advantage is that all of the asio functions can be written in terms of that, getting buffer overrun protection for free, and there's no (or extremely little) added overhead. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;

From: Thore Karlsen <sid@6581.com>

On Fri, 19 Aug 2005 09:08:59 -0400, Rob Stewart <stewart@sig.com> wrote:

...

...

The performance problems of requiring vector<char> or char[N] exist on several levels:

- For vector<char>, there is the initialisation of the chars to 0 on construction or when you do a resize. Note that this is proportional to the size of the vector, not necessarily to the amount of data transferred. I have seen this have a noticable cost in a CPU-bound server handling thousands of connections.

...

Don't construct a vector of a given size or use resize(), then. Rely on reserve() instead.

Then size() will return the wrong value, and relying on capacity() is

No, size() will correctly indicate that there are no objects in the vector.

not a good idea. If you're thinking about pushing data onto the vector

Why is relying on capacity() a bad idea?

as it's read, that's also bad, because then you'd have to read into a temporary buffer first and copy it to the vector after. (Or do multiple resizes.)

At some point, the vector has to have sufficient elements in it so that you can copy new values onto them. Otherwise, the vector won't know it has real elements. Yes, that means you do pay for the initialization at some point and, yes, that isn't desirable.

I think it's a very bad idea to require vector<char> or a static array. Christopher does a good job of explaining the drawbacks, and I agree with him. I also do high performance asynchronous networking in my server and client applications, and a library requiring vector<char> or a static array would be completely useless to me. Most of the time I don't have the data I want to send in a vector or in a static array, and most of the time the amount of data is too big to send or receive a whole buffer at a time.

I understand.

...

...

- Requiring a copy from a native data structure into vector<char> or char[N]. If I have an array of a doubles say, I should be able to send it as-is to a peer that has identical architecture and compiler. Avoiding unnecessary data copying is a vital part of implementing high performance protocols.

...

Agreed. OTOH, using swap(), *if* a user used a vector<double> instead of the array you mention, then vector won't add overhead.

Why would a swap be necessary?

If asio used a vector, the user could swap it's contents into his own vector. (That's not the current interface, but then neither is vector in the current interface. It was just informational for the discussion.)

...

Instead, how about a std::vector-like class that takes a user-defined, fixed-size block of memory?

No, that would still require a copy if the data isn't already in such a buffer. void * (or unsigned char *, or char *, or whatever) HAS to be there, otherwise the library is useless. Such a class could be an option (and I would like to see it as an option), but not a requirement.

I don't think you understand what I'm suggesting. Notice that I used the word "takes." Furthermore, I think you snipped the details about how that class would use the buffer handed to it. The data has to be in some memory somewhere. The class I'm suggesting can be told to use that memory and can be told how much memory is available. Then, whenever asio needs to read data into the caller's buffer, or write data from the caller's buffer, it is taken from that preexisting buffer.

In my applications I can't afford to copy data from my internal buffers to whatever the networking library requires. I also can't put the data in such buffers to begin with.

So wrap your internal buffers with the class I'm suggesting. No copy is needed. The class simply provides a standard interface, complete with push_back(), iterators, random access, etc., and prevents buffer overruns. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;

Hi Rob, --- Rob Stewart <stewart@sig.com> wrote:

From: Christopher Kohlhoff <chris@kohlhoff.com> Don't construct a vector of a given size or use resize(), then. Rely on reserve() instead.

It's my understanding that you cannot access the address &vec[N] (or &vec[0] + N) unless 0 <= N < size(), and reserve() doesn't change the size of the vector.

OTOH, using swap(), *if* a user used a vector<double> instead of the array you mention, then vector won't add overhead.

But Thorsten was proposing only the use of vector<char>, so you would still need to convert from vector<double> to vector<char>.

Instead, how about a std::vector-like class that takes a user-defined, fixed-size block of memory? Then, instead of using an allocator, it uses its own memory management class that doles out elements from the fixed, user-supplied memory. Such a class could even avoid the default construction worry altogether by eliminating resize() and making the constructor that takes a number simply reserve that much space. (Deviating that much from std::vector means you wouldn't want to make it too similar, or at least you'd want the name to be quite dissimilar.) Using a user-supplied block of memory means that the memory can come from a stack allocation, static memory, the free store, a memory mapped file, etc. That class cannot be copyable, but it could be movable and swappable.

I'd be happy to look at a proposed interface for it, if you'd like to sketch it out. However it would have to provide a straightforward way of sending an existing application data structure (and it may be hard to beat void* for that) that doesn't add time or space overhead in an optimised build. Basically I'm still of the opinion that the operations on the socket class should deal in void* to allow for users that need to be close to the metal. But since safe, efficient buffer management seems to be a common need/desire, perhaps there is a place for that in asio with a buffer class (or should it be a Buffer concept?) and non-member send/recv functions. Cheers, Chris

"Thorsten Ottosen" <nesotto@cs.aau.dk> writes: [snip]

I'm proposing a lot. In one mail I wrote vector<T>. I don't know what's required, if you can only send chars or not. So if you need to send arbitrary data, then just allow both T (&)[N] and vector<T>. (so no copy needed)

Aside from all the other reasons for not requiring the use of vector, which I believe are sufficient, there are also the following problems: If reading a type other than char is allowed, it is difficult to have a useful interface for the simple "recv" and "recv_at_leaast_n" versions, because the total number of bytes read might not be divisible by sizeof(T). Thus, the library would still need to tell the user the number of bytes read, rather than the number of T read, and the `offset' parameter would also need to be specified in bytes, rather than in number of T, so that these partial reads could be completed; these limitations would surely negate any benefit of allowing reading T rather than just char. (Trying to ensure that the number of bytes read is divisible by sizeof(T) is not really feasible.) Another issue is that in the case that T is a large structure, the user may only want to read a single one, in which case it would be undesirable to have to use either an array or a vector. [snip] -- Jeremy Maitin-Shepard

"David Abrahams" <dave@boost-consulting.com> wrote in message news:uslx5zzp4.fsf@boost-consulting.com...

There's been some discussion of providing a vector ctor (and assign member) that takes a number of elements and function object that can be used to construct the elements into its raw memory. Until we have that, std::vector is probably the wrong tool for this job.

I'll consider to put this on my STL enhancements paper. br -Thorsten

Caleb Epstein wrote:

Reading back through my comments (below), I don't think any of the Missing Features is a show-stopper. I'd say rationalizing interfaces for inclusion in Boost (e.g. perhaps using boost::xtime instead of asio::time, etc) and expanding the documentation and example code would be the top priority. All IMHO of course. {snip}

...

* The asio::time class should probably not be included, and wherever it's used replaced by Boost.Date-Time.

I think boost::xtime is the right choice there.

Am I the only one who dislikes boost::xtime? IMO it makes much more sense to replace boost::xtime with a convenient class like asio::time.

Caleb Epstein wrote:

...

* Obviously asio::thread should not be part of a boost proposal, since that functionality is already covered by Boost.Thread.

I do very much enjoy the 100% header implementation you have now, but having to link to a library would not be a show-stopper. It does seem a bit of a shame that a number of Boost libraries that are thread-safe/aware (SharedPtr, Pool, Regex) have provided their own e.g. mutex classes instead of using the ones in Boost.Threads. This is not a value judgement, just an observation.

I guess they would not, if required part of functionality of Boost.Thread was available as a header-only implementation (ie. could be used without introducing dependency on library files) B.

Mr Minh wrote:

Chris,

how would the iostreams source/sink fit into your design and would you consider using signal/slots to handle the events.

Minh

Christopher Kohlhoff <chris@kohlhoff.com> wrote: As discussed in the "surveying async network io libraries" thread, I'd

[cut complete reply quote] FYI... http://www.boost.org/more/discussion_policy.htm#effective Don't Overquote Please prune extraneous quoted text from replies so that only the relevant parts are included. [...] -- -- 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

Hi Stefan, --- Stefan Arentz <stefan.arentz@norad.org> wrote:

Maybe I'm wrong, but I thought most resolvers included with the operating systems are not thread safe and synchronous. Maybe only OS X has it's own async implementation. There are of course third party libraries to do this.

I was thinking that an initial implementation could just use an internal thread pool to perform the operations using the existing blocking functions provided by the OS (unless the OS already provided a straightforward way to do it).

What is the Boost policy of linking with foreign libraries? If everything is supposed to happen under the boost umbrella, under the boost source tree then maybe it is an idea to write our own async resolver? Could be a fun spare time project (for me :-).

Sounds like fun ;)

...

* IPv6 support. I have no experience with IPv6, so it would be great if someone with experience could help out with the design here.

It is mostly about abstracting addresses and endpoints. Something asio already has right?

Yes, but it would probably be best for someone who is familiar with using IPv6 in real apps to oversee the design of the asio::ipv6::* classes.

I sort of have a http server example ready. Needs a little bit more love though, then i'll release it or send it to you to see if you want to include it in the distribution.

That would be excellent! Cheers, Chris

Stefan Arentz wrote:

...

* Asynchronous DNS operations. I think it would be reasonable to say that any operation that can block should have an asynchronous equivalent. Should these operations be cancellable (not necessarily portably implementable anyway)?

Maybe I'm wrong, but I thought most resolvers included with the operating systems are not thread safe and synchronous. Maybe only OS X has it's own async implementation. There are of course third party libraries to do this.

What is the Boost policy of linking with foreign libraries? If everything is supposed to happen under the boost umbrella, under the boost source tree then maybe it is an idea to write our own async resolver? Could be a fun spare time project (for me :-).

Last time I checked, GNU libc had asynchronous name resolution functions. I don't know if those are standard or extensions. -- Pedro Lamarão Desenvolvimento Intersix Technologies S.A. SP: (55 11 3803-9300) RJ: (55 21 3852-3240) www.intersix.com.br Your Security is our Business

Hi Minh, --- Mr Minh <m_phanivong@yahoo.com.au> wrote:

how would the iostreams source/sink fit into your design

I'm not particular familiar with the Boost.Iostreams library, but it seems that template adapters could be used to turn the Sync_Recv_Stream concept into a Source, and a Sync_Send_Stream into a Sink. There does not seem to be an equivalent for the async concepts though.

and would you consider using signal/slots to handle the events.

The current design makes the callback function object (aka Handler) type a template parameter to give maximum scope for optimisation. However there is no reason that I can see why you can't pass a signal to be the handler. For example: //------------------------------ #include <boost/signal.hpp> #include <boost/bind.hpp> #include <asio.hpp> #include <iostream> void func(int value) { std::cout << value << std::endl; } int main() { boost::signal<void()> sig; sig.connect(boost::bind(func, 1)); sig.connect(boost::bind(func, 2)); asio::demuxer d; d.post(boost::bind(boost::ref(sig))); d.run(); return 0; } //------------------------------ Cheers, Chris

On Aug 19, 2005, at 7:07 AM, Peter Simons wrote:

I recall reading in the Boost.Signal documentation that the library is not thread-safe; meaning, it will probably do weird things when several threads register/unregister a callback simultaneously, etc.

Has this limitation been addressed in the more recent versions of the library?

No, it hasn't :( Signals has fallen way behind in its development. I've hardly even had the time to maintain it adequately, much less implement new features. Doug

Christopher Kohlhoff wrote:

There's a simpler way to do what you want. Just call demuxer.work_started() before calling demuxer.run(), and then call demuxer.work_finished() when you're ready to shut down.

These functions are provided to ensure that demuxer.run() does not exit when an asynchronous operation (the "work") is being carried out by something external to the demuxer (such as a thread).

I see, thanks!

From: Christopher Kohlhoff <chris@kohlhoff.com>

--- Felipe Magno de Almeida <felipe.m.almeida@gmail.com> wrote:

...

win_iocp_operation is a base class that takes a pointer to a function and when called(when the IO operation is completed) it executes its pointer. The pointer is normally a static function to a derived class that calls the apropriate handler. [snip] But I dont quite follow the virtual function overhead in this case. I think that asio is reinventing the wheel and with the same overhead.

The overhead is not the virtual function call itself, but all the other stuff that gets generated by the compiler as soon as you add a virtual function to a class (e.g. vtable, RTTI etc).

Should that interface take an extra argument (void *, for example) that permits the client to get back some context? The client may need to provide a this pointer or allocate a structure on the free store and get back data needed to correctly react. If you provide for context, then you might want to combine the function pointer and context information into an object that will keep the values together not only in the win_iocp_operation invocation mentioned above, but in data members and other function calls that follow. That helps the client to combine them properly and it helps asio to keep them correctly associated. (If there are no other arguments to the win_iocp_operation invocation, then the client needn't be bothered with creating such a structure, but the implementation might still want to.) -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;

On 8/31/05, Christopher Kohlhoff <chris@kohlhoff.com> wrote:

Hi Felipe,

Hi Christopher,

The overhead is not the virtual function call itself, but all the other stuff that gets generated by the compiler as soon as you add a virtual function to a class (e.g. vtable, RTTI etc).

Now I see. But.. Does it worth rewriting virtual mechanisms? I think that boost libraries rely a lot on compilers doing the right job and write code that, when possible, are elegant. I think it is a lot more readable with virtual functions. And it's not only with win_iocp_operation that this happens I think.

Since you can very easily end up with many win_iocp_operation-derived classes in your application (one for each callback handler) using virtual functions can contribute to significant code bloat on some compilers (e.g. MSVC6, although with MSVC7.1 it appears to optimise unused RTTI away).

I can only enumerate two classes deriving from win_iocp_operation, no matter how the client uses the normal interface of library. The two I think are: win_iocp_demuxer_service::read_operation and win_iocp_demuxer_service::write_operation.

By doing this little workaround, I can guarantee for all compilers that the overhead for each handler is limited to a single function, which is called through a function pointer.

AFAICS, this workaround is only effective with VC6. I'm only saying all this because I'd like to have all libraries in boost rewriting virtual mechanisms.

Cheers, Chris

Thanks Chris, Felipe. -- Felipe Magno de Almeida Developer from synergy and Computer Science student from State University of Campinas(UNICAMP). Unicamp: http://www.ic.unicamp.br Synergy: http://www.synergy.com.br "There is no dark side of the moon really. Matter of fact it's all dark."

From: Felipe Magno de Almeida <felipe.m.almeida@gmail.com>

On 8/31/05, Christopher Kohlhoff <chris@kohlhoff.com> wrote:

...

The overhead is not the virtual function call itself, but all the other stuff that gets generated by the compiler as soon as you add a virtual function to a class (e.g. vtable, RTTI etc).

Now I see. But.. Does it worth rewriting virtual mechanisms? I think that boost libraries rely a lot on compilers doing the right job and write code that, when possible, are elegant. I think it is a lot more readable with virtual functions. And it's not only with win_iocp_operation that this happens I think.

If this is only intended to be "overridden" via the function pointer in a few derived classes, I agree with you that avoiding virtual functions is confusing at best. (I jumped into the middle of the discussion and thought that unrelated functions might be passed as arguments.) I'd say that unless you know that using virtual functions causes problems, you shouldn't presume that they do. If users say the library is too big and this technique significantly affects the size, then it may be worth considering at that time. You might also consider whether the Strategy pattern applies here. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;

From: Christopher Kohlhoff <chris@kohlhoff.com>

--- Rob Stewart <stewart@sig.com> wrote:

...

I'd say that unless you know that using virtual functions causes problems, you shouldn't presume that they do. If users say the library is too big and this technique significantly affects the size, then it may be worth considering at that time.

As I said in another reply, I did find a need to do this change to eliminate code bloat with several compilers. As an example, Borland C++ 5.6.4 seems to add approximately 100 bytes to the executable for each asynchronous call if a virtual function is used in win_iocp_operation. As the change didn't impact the public interface of asio, it seemed like a win.

Was that 100 bytes per async call or per type of call? As I understand it, you have a class template derived from win_iocp_operation. Is it 100 bytes for each class created by specializing that template? Is there a reasonable upper bound on the number of such types in a given application? -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;

Hi Felipe, --- Felipe Magno de Almeida <felipe.m.almeida@gmail.com> wrote:

Does it worth rewriting virtual mechanisms? I think that boost libraries rely a lot on compilers doing the right job and write code that, when possible, are elegant. I think it is a lot more readable with virtual functions. And it's not only with win_iocp_operation that this happens I think.

I think it was worth doing (otherwise I wouldn't have done it :) ). It reduces code bloat with several compilers and did not affect the public interface of asio.

I can only enumerate two classes deriving from win_iocp_operation, no matter how the client uses the normal interface of library. The two I think are: win_iocp_demuxer_service::read_operation and win_iocp_demuxer_service::write_operation.

I used the technique where the derived classes are templates, and you are likely to end up with hundreds of them in a typical program. Each of those win_iocp_operation-derived classes takes a Handler as a template argument, so whenever you write: socket_.async_send(buf, length, boost::bind(...)); you would create a new win_iocp_operation-derived class.

AFAICS, this workaround is only effective with VC6. I'm only saying all this because I'd like to have all libraries in boost rewriting virtual mechanisms.

And Borland C++ too, if I remember correctly. Boost.Function takes a similar approach: boost_1_33_0/doc/html/function/misc.html#id1215202 Cheers, Chris