On Nov 3, 2003, at 5:33 AM, Dalibor Topic wrote:
For what it's worth, yes, there is code out there that expects threads
to be able to read from readers/writers and not trip over their feet
;) AFAIK, the Java APIs explicitely mention when a method/class is not
thread safe, so by default we
Hi,
On Sun, 2003-11-02 at 21:11, Guilhem Lavaux wrote:
Mark Wielaard wrote:
OK. Let me try to summarize the behavior we want so we can at least
create some good tests:
DataInputStream.readLine():
- Should not block when it has seen at least a \r but return as soon as
possible even
Hi,
On Fri, 2003-10-31 at 19:12, Guilhem Lavaux wrote:
Continuing the Classpath-Kaffe merge, I noticed that
DataInputStream is failing one of kaffe's regression test
(InputStreamTest). It seems the failure comes from
readLine(): readLine() is a little too conservative compared
to JDK's
Mark Wielaard wrote:
Hi,
On Fri, 2003-10-31 at 19:12, Guilhem Lavaux wrote:
Continuing the Classpath-Kaffe merge, I noticed that
DataInputStream is failing one of kaffe's regression test
(InputStreamTest). It seems the failure comes from
readLine(): readLine() is a little too conservative
Hi,
On Sun, 2003-11-02 at 17:33, Dalibor Topic wrote:
That's a bug in Classpath then. Trying to 'read ahead' after \r fails on
for those systems whose 'end of line' is a plain \r.
[...]
In fact, while you're at it, check out the rationale behind kaffe's
implementation as described in
Mark Wielaard wrote:
OK. Let me try to summarize the behavior we want so we can at least
create some good tests:
DataInputStream.readLine():
- Should not block when it has seen at least a \r but return as soon as
possible even when it cannot be sure that the next character is or
isn't a \n to
Hi,
Continuing the Classpath-Kaffe merge, I noticed that
DataInputStream is failing one of kaffe's regression test
(InputStreamTest). It seems the failure comes from
readLine(): readLine() is a little too conservative compared
to JDK's implementation. The real behaviour seems to be the
7 matches
Mail list logo
