This is a request for review of a minor test bug that causes the
aforementioned test to fail intermittently. The issue is that the
mock test server expects to read the complete HTTP request with
a single read call. It should, however, be prepared to perform
more than one read call.
Webrev:
http
Hi Vyom,
Looks fine to me too.
My only concern was adding an intensive test (used to be a stress test)
to the normal
test cycles. I'd be more comfortable with it being in a separate/lower
tier or as @manual.
Roger
On 9/24/2017 1:15 PM, Chris Hegarty wrote:
On 15 Sep 2017, at 10:29, vyom
Looks fine.
Regards,
Sean.
On 25/09/17 11:40, Chris Hegarty wrote:
This is a request for review of a minor test bug that causes the
aforementioned test to fail intermittently. The issue is that the
mock test server expects to read the complete HTTP request with
a single read call. It should, ho
On Monday 25 September 2017 08:08 PM, Roger Riggs wrote:
Hi Vyom,
Looks fine to me too.
My only concern was adding an intensive test (used to be a stress
test) to the normal
test cycles. I'd be more comfortable with it being in a
separate/lower tier or as @manual.
thanks for review, i will
Ping.
Please review the proposed change at your convenience.
The fix will greatly reduce the possibility of a need to reallocate the
buffer to retrieve the results (something that the documentation
strongly suggests to avoid), and, if such reallocation still occurs to
be necessary, will incre
Hi Ivan,
Looks ok to me.
I don't see a reason to skimp on the additional size since it is
allocated and then freed immediately.
The increment might as well be as big as the initial size.
I don't see a reason to retry if the buffer gets close to ULONG_MAX; I'd
just break the for loop
and let
Thank you Roger for review!
On 9/25/17 11:47 AM, Roger Riggs wrote:
Hi Ivan,
Looks ok to me.
I don't see a reason to skimp on the additional size since it is
allocated and then freed immediately.
The increment might as well be as big as the initial size.
Right. Let's use the same value of
Hi Ivan,
Looks fine,
Thanks, Roger
On 9/25/2017 4:58 PM, Ivan Gerasimov wrote:
Thank you Roger for review!
On 9/25/17 11:47 AM, Roger Riggs wrote:
Hi Ivan,
Looks ok to me.
I don't see a reason to skimp on the additional size since it is
allocated and then freed immediately.
The incremen
On Tuesday 26 September 2017 02:28 AM, Ivan Gerasimov wrote:
Thank you Roger for review!
On 9/25/17 11:47 AM, Roger Riggs wrote:
Hi Ivan,
Looks ok to me.
I don't see a reason to skimp on the additional size since it is
allocated and then freed immediately.
The increment might as well be
