On Tue, Dec 10, 2013 at 07:52:33PM +0100, Daniel Stenberg wrote: > On Tue, 10 Dec 2013, Mohammad_AlSaleh wrote: > > You didn't mention which libcurl version on which platform you're using! >
7.33.0 (GNU/Linux x86_64) > >A small test case is attached to help me explain. It's not a real-world > >use case. > > CURLOPT_MAX_RECV_SPEED_LARGE on a file:// URL is not supported, and > not a good idea. Although it also shouldn't harm anything. > It doesn't make sense anyway. I just used it to exaggerate the effects of the behaviour I'm trying to describe. > >1- All required data is read fast. > > > >2- dlnow will report a completed transfer early on. > > (It only represents the size of data received/read). > > > >3- Not all data is flushed after writes > > (unless you uncomment the fflush line). > > > >4- libcurl will keep waiting until the speed limit is met on a now > > long interval. > > > >5- Finally, the remaining (unflushed) data is written. > > Apart from (4), isn't that the exact same procedure as without > CURLOPT_MAX_RECV_SPEED_LARGE? That waiting certainly sounds like a > bug. > Yes. That's the point I was trying to make. It waits even if there is no more data to read. > And libcurl never flushes the output, it shouldn't need to. If you > want that done, use a callback and add whatever you think is > necessary! > > -- > > / daniel.haxx.se > ------------------------------------------------------------------- > List admin: http://cool.haxx.se/list/listinfo/curl-library > Etiquette: http://curl.haxx.se/mail/etiquette.html ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
