[kaffe] DataInputStream related merge

[Dalibor Topic]

Hi Jukka,

--- Jukka Santala <jsantala@morphine.tml.hut.fi>
wrote:
> Fairly straightforward merge from PocketLinux
> version, only problem is
> neither version of Kaffe has exact implementation.

could you give pat's serialization patch a try and see
how that works in your context?

You can find the details at:
http://www.kaffe.org/pipermail/kaffe/2002-September/008900.html

> With Kaffe.org's
> version the problem is actually encountered, though
> - using Xerces XML
> parser, the HTTP code will eat out the headers using
> readLine, but then
> Xerces will use something else than DataInputStream
> to parse the remaining
> data. Because that reader doesn't know to eat the
> extra line-feed, it gets
> stuck at the beginning of the parse-input, which
> then doesn't fullfill the
> XML-production condition, and causes all XML
> documents read over HTTP to
> fail. If anybody can come up with an implementation
> that doesn't need
> mark()/reset(), I'd be happy. If not, this corrects
> few exception issues
> and at least works, unlike the old code :)

Hm. I'm not convinced. There are two ways to handle
the \r vs. \r\n ambiguity while reading lines. When a
line reading IO class reads a \r it can not tell if
that's the beginning of a \r\n newline sequence or
just a plain \r newline sequence. One can:
a) read one char ahead and check if it's \n; push it
back if it isn't.
b) set a flag to ignore the next char if it is \n.

I choose the second approach in all IO classes I
worked with in order to prevent the classical hung on
a socket bug. Imagine a client implementing method a
sending a request to a server, that returns a \r
terminated reply without closing the socket. The
client tries to read ahead and hangs because the
server has nothing left to send. Ugly.

Check out
http://developer.apple.com/technotes/tn/tn1157.html
for more information on this bug.

I switched DataInputStream to method b recently for
that reason. I don't think going back to the previous
version is a good idea, as it fixes one bug by
introducing another.

Instead of using mark and reset one could use a
pushback input stream with a single byte buffer, but
that's still method a.

In any case it would be great if you could come up
with a small test for the regression test suite as
this bug is not covered by it and we don't have that
many networking tests anyway.

It may be a bug in our HTTP handling code, for
example. A small test could help me come up with a
less invasive solution ;)

best regards
dalibor topic

__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com