David Abrahams wrote:
Of course, like anything else, asio is not perfect -- a number of key issues were uncovered during the review. In terms of required changes I'm only going to cite a few:
- Fixes to dynamic memory allocation issues - Interface changes to support ipv4 and ipv6 seamlessly at runtime - Improvements to support strongly typed socket interfaces
If you're only citing a few of the required changes, where is the complete list? Keeping it out of public view doesn't make any sense to me.
What I was trying to say was that I was only requiring a 3 changes -- so that's the entire list. My feeling was these were the only 'must-have' changes even though there was certainly discussion of other changes and extensions.
Chris has communicated a couple possible solutions to the memory allocation issue and I'll ask that the interface and other changes for this issue continue to be discussed on the Boost list so consensus can be achieved on the best resolution.
Other key improvements that should be explored as future enhancements include:
- Possible removal of some of the c-style interfaces - Exploration of higher level iostream integrations - Performance improvements - Improved documentation (wouldn't be Boost w/o this one)
Chris has a much longer list of changes garnered from the review and is well on his way to addressing many of them.
Note that there were several threads and discussions about performance, which is particularly critical for the domain covered by asio. One of the performance issues is the dynamic memory allocation issue cited above. In general, the reviewers have extremely high expectations here. However, after reviewing the discussion and library it's my belief that many developers will find asio performance sufficient to build significant projects with only the memory allocation changes. I expect Chris will be able to address some of the other performance issues cited by reviewers in asio over time.
Are these issues addressable as an implementation detail, or will it cause an interface change?
I believe they are only implementation details (seems that Chris agrees with this) -- the c-style interfaces issue being the exception. But it is a large library so it's possible we've missed something in the public interface that will need to change. As for the c-style interfaces, the review discussion wasn't sufficient to convince me that it was a possible change and the benefits weren't clear so I'm leaving it to the discretion of the library author. Jeff