[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] read-response-body should return received data when error oc

From: Nala Ginrut
Subject: Re: [PATCH] read-response-body should return received data when error occcurs (V2)
Date: Sat, 17 Mar 2012 10:26:40 +0800

Wrong thread but interesting ;-)
Could you resend it to the correct thread? Maybe helpful to people there.


On Sat, Mar 17, 2012 at 12:27 AM, Tristan Colgate <address@hidden> wrote:
I got this the other day with lalr.scm. My build got stuck (100% CPU
for quite a while). I ended up clearing out all old .go files and
trying again and it got past it (didn't even take that long, a few
seconds compared to a 15 minute wait).

On 16 March 2012 08:47, Nala Ginrut <address@hidden> wrote:
> Well, I saw your point. So read-response-body is defined to read the whole
> body, and shouldn't return anything when it didn't get all the data.
> For this reason, one should use bytevector handler to get the data on one's
> own rather than read-response-body.
> Well, I just thought read-response-body is the only API to get body, at
> least from the manual, I can only get this conclusion. But in fact, the
> worth of read-response-body is very limited. It just a simple procedure to
> get a simple page or few data.
> If possible, I wish the manual can add few words to notice this.
> On Fri, Mar 16, 2012 at 3:32 PM, Daniel Hartwig <address@hidden> wrote:
>> On 16 March 2012 13:54, Nala Ginrut <address@hidden> wrote:
>> > This patch will return any data get-bytevector-n received and throw
>> > error
>> > when get <eof>.
>> > Actually, it's not the same feature in the old version thread
>> >
>> > The old version is complicated because it catches *any* exception and
>> > return
>> > the received data within exception.
>> > But this new version is an easy one.
>> Yes, it looks much nicer :-)
>> > My point is, read-response-body is a low level procedure, so we
>> > shouldn't
>> > make it complex. But our current doesn't return received data when
>> > the received data is less than the content-length. I think it should
>> > return
>> > it, and let the user  determine whether it's an error or continue
>> > reading.
>> So r-r-b is a really a two-liner:
>> - read response body from port;
>> - make sure the complete response has been read.
>> This combination is the utility of the procedure: it guarentees that
>> the data it returns comprises the complete response body.
>> With your proposed change, that guarentee no longer holds.  The caller
>> now must perform their own checks on the response data size, making
>> your function effectively this:
>> - read response body data from port.
>> So what is the utility of calling a procedure to do that over, say,
>> reading from the port directly? [pointed out earlier in this thread]

Tristan Colgate-McFarlane
  "You can get all your daily vitamins from 52 pints of guiness, and a
glass of milk"

reply via email to

[Prev in Thread] Current Thread [Next in Thread]