Hi Jukka, --- Jukka Santala <[EMAIL PROTECTED]> wrote: > On Wed, 23 Oct 2002, Dalibor Topic wrote: > > > Actually, the switch to method b fixed one bug > by > > > introducing another ;) > > Yeah, sorry about that. Could you try the attached > > patch and see if it works in your context? It is > an > > attempt to get the best of both worlds, and runs > your > > test case as expected. > > Thanks for the fast response, yeah the patch does > work... However, it's > starting to get worrisomely complex. In particular, > if for some reason > there's a break in the stream right between the cr > and lf, which could > easily happen with IP-frames etc., it'll lead to > hard to track down > problems. It may be best to apply that for now, but > on the logn run I'd > still like to see skipNextLF moved to lower level, > possibly native code.
The proposed solution is not optimal, but I'll apply it for now, as it solves your problem, and is less invasive than the other patch. I don't know a lot about kaffe's networking libraries, so I can't tell how easily the midstream corruption could happen. Note that in most cases nothing bad will happen, unless someone tries to read from the underlying stream while DataInputStream is not done with it. In my eyes "stealing" streams is bad programming practice, but I haven't looked at the XML processing code that triggered the error, so I can't tell how reasonable my opinion on "stealing" streams is. > This remaidns me of a related optimization issue, is > there any kind of > plicy/guideline on native code vs. Java in the > default lib? It seems > implemnting at least some of the more trivial IO > classes in native code > could yield significant speed-ups for them. There is no policy as far as I know. I tend to prefer to do things in Java, as that is easier to maintain for me, and avoids all the auto* trickery as much as possible (broken strtod, memove etc. functions on different platforms). For example, replacing the native System.arraycopy by a pure java version yielded a significant performance improvement for the SciMark2 benchmark on i386-linux with jit3. I didn't expect that. Other people (IBM) have implemented the BigNum classes in java.math in pure java and were faster than the native versions. Just because it's in Java doesn't have to mean it's slow ;) Do you have some specific classes/methods in mind that you'd like to see go native? best regards, dalibor topic __________________________________________________ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/ _______________________________________________ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe