Hi Ron, --- Ronald Garcia <garcia@cs.indiana.edu> wrote:
Some of the tutorial material seems too low-level with respect to the facilities available from the C++ Standard Library. Why the use of char arrays, strdup, and strlen? Furthermore, is strdup a standard C++ function? I do not think it is standard C.
Yep, good point. I'll change the tutorials to use things like std::vector or std::string.
I would like to see an interface for reading/writing that supports iterators if that makes sense.
I'm not sure if it does make sense, as the socket operations must operate on contiguous sequences of bytes, which is not something that iterators enforce. However, it might be feasible to support iterators on containers of POD types. For example, an overload of buffer: template <typename Iterator> unspecified buffer(Iterator begin, Iterator end); which could be used: std::list<pod_type> data; ... sock.write(asio::buffer(data.begin(), data.end())); The main problem with this approach is that it might mask inefficiencies: - The number of elements in the returned list of buffers cannot be determined until runtime, and so the return type of the buffer() overload would have to be something like std::vector or std::list. - The number of elements might be very large, and so would require multiple underlying read/write system calls to transfer. - The size of pod_type might be small, so it might be more costly to copy the list of buffers than to simply copy the POD values into contiguous storage (e.g. a vector) first. - For implementations where std::vector<>::iterator is not a pointer it probably wouldn't be possible to optimise to use the already contiguous data in a single buffer. I'm interested to know if you or others still see direct iterator support as a useful thing to have, in light of the above. If it is widely useful I'd be happy to add it.
It would also be nice to be able to read from a socket into an std::string. If that is possible, then it is not obvious from the tutorial.
The problem with std::string is that it doesn't give you write access to an underlying buffer (as say std::vector does). This means that a read into a string is always going to involve a separate read into some other buffer first, and then a copy of the data into the string. That's not to say read support for std::string shouldn't be added, but it would have to be as a new function (e.g. read_string/async_read_string) rather than hooking into the existing read functions.
Based on the daytime tutorial, I am concerned that not enough high-level functionality has been added to the library. The daytime examples still have the flavor of using unix sockets. I think that this low-level functionality is critical to flexibility (and perhaps performance), but I would like to be able to quickly construct simple network applications as well.
I'd like to see something like this layered on top of asio as a separate framework. There are many different styles and approaches to take, so it may actually be multiple frameworks :)
I did not find the Timer 5 example (Using boost threads) to be very compelling. Granted the examples are meant to give a flavor of the library interface, but it may be more compelling to defer multi-threading to the daytime server, perhaps forking a new thread on each connection. This would probably more closely resemble a real use of the facility. I suspect that something more would need to be done to demonstrate synchronization.
Fair enough, I'll have a think about a better example to demonstrate multithreading.
I am also curious if the library could provide synchronous networking (which asio supports contrary to the library's name) through an iostreams-like interface as well.
Yep, see the included iostreams example. I plan to tidy the interface up a bit and make this part of the library itself.
Demuxer: It appears that any application that uses asio must have one and only one demuxer object floating around. If that is the case, then perhaps it would be wise to model demuxer after std::cout: a global object that is implicitly constructed and destructed and available to any translation unit that includes the relevant header.
Actually no, you can have multiple demuxers in a single program. This can be used, for example, to partition a program's I/O functionality into multiple single-threaded components. <snip>
2) How can one interleave asio's demultiplexing facilities with other existing event-based libraries. I'm afraid I have not had time to investigate whether and how this can be done in asio currently. But some applications will require mixing asio into some other master event loop. Something of like demuxer::run_one_event() would be a good start.
Based on other feedback, I already plan to add demuxer::run() overloads that take a timeout indicating the maximum time that they are allowed to execute. <snip>
Code Comments:
It was necessary for me to make the following changes to the library in order to prevent warnings and to compile under OS X (Panther/10.3): <snip>
Unfortunately there are other issues with support for 10.3, such as the lack of thread-safe DNS functions. Cheers, Chris