apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Stoddard <b...@wstoddard.com>
Subject Re: Win32 apr_sockets; Random notes from the 'oh, duh' department
Date Thu, 24 Apr 2003 18:15:40 GMT

>>That should not be the case. Last time I checked, I though we set the timeout 
>>then sent 64K (?) chunks then reset the timeout for the next 64k chunk. 
>>This is -eaxactly- what 1.3 does on Unix (where signals are used as the 
>>timeout mechanism). This has someone changed that w/o my noticing? 
>>I'll check later...
> No, especially not in the case of mmaps.  The way filters, brigades and
> buckets work, you can end up with a 16MB sendfile or 4MB mmap.  In
> the later case, you may have 4MB * 16 iovecs in a single WSASend.

Humm... I am wondering if breaking up sends should really be the 
responsibility of APR. Consider that the application sets the send 
timeout, the application understands how its expected to behave and what 
kind of link it is talking over. Seems it should be able to control the 
size of the buffer to send and the time it will allow for it to be sent. 
  Using that line of reasoning, one could argue that if the app (httpd 
in this case) sent to APR a 4MB mmap to send but did not set an 
appropriate timeout, that it is httpd that is at fault if the send does 
not complete before the timeout fires.

I agree that some kind of progress indicator would be the best solution.


View raw message