> I attached a little patch that reimplements the used methods of the BIS.
> It should be a little bit faster because it doesn't implement marks.
> Not sure if it is worth the extra code because read() isn't called very
> often anyway and if read(byte []) is used anywhere then it should be
> rewri
Remy Maucherat wrote:
>
> I can't see why. Is my interpretation on what will happen at the next
> iteration wrong ?
>
You are perfectly right. Sorry, I misunderstood the loop (didn't realize
the pos=0 after the read()).
A problem could only arrise if somewhere else a mark is set before your
Quoting Thomas Butter <[EMAIL PROTECTED]>:
>I think the problem won't be triggered by a small buffer,
>but by tcp packet that ends 1 byte after the current buffer.
>If the next packet didn't arrive when fill() is triggered
>the next time then pos==0 and count==1, the read then does a
>pos++.
Her
Remy Maucherat wrote:
[EMAIL PROTECTED]">Quoting Thomas Butter <[EMAIL PROTECTED]>:
For example if in line 257: requestLine.uri[readCount] = (char) buf[pos]; readCount++; pos++;buf[pos] is undefined the last fill called by the last read() only got one byte
> > I would volunteer rewriting this class if you agree with my
> > assumptions.
>
> If extending BIS is indeed a problem, I would vote +1 in duplicating the
BIS
> code into SocketInputStream, and -1 for layering another IS (for
performance
> reasons).
Yeah, I agree. Assuming you're talking about
Quoting Thomas Butter <[EMAIL PROTECTED]>:
> For example if in line 257:
>requestLine.uri[readCount] = (char) buf[pos];
>readCount++;
>pos++;
>
> buf[pos] is undefined the last fill called by the last read() only got
> one byte (which was enough fo
SocketInputStream extends java.io.BufferedInputStream and uses the
protected fields buf, pos and count.
As far as I can see there are several problems with some uses of pos:
First of all the use of buf and pos are not defined by the api, so it is
theoretical implementation dependent.
Furthermo
