> Right, but the current fixed-size 32K (16+16) allocation could easily be converted into a more dynamic way that either would automatically grow according to some rule or it could be possible to set with an option.
> A first and simple zero-copy implementation for libcurl would still have to provide the same sized buffer to libcurl since it internally always assume and work with 16K now. I'll try to explain a little bit more: Currently each easy handle has its own 2 buffers with fixed size of 16K. This enforces the application that uses libcurl to copy the data when the callbacks are called, since it will not be valid after the callback return. If curl will request the buffer from the application (just when it is needed), then the application will not need to copy the data during the callback (it is already written in the right place) and it'll also reduce the memory foot print of curl (assuming that it'll also ask the application to free the buffer after it is not needed). Of course dynamic allocation could also be implemented inside curl - this will solve the memory foot print, but not the zero copy. Maybe such implementation could be used as default, in case the application don't want to handle the buffers management or don't mind to copy the data. Yehezkel ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
