Am Dienstag, den 05.12.2006, 10:52 +0000 schrieb Andrew Haley: > Mark Wielaard writes: > > Hi, > > > > On Tue, 2006-12-05 at 11:04 +0100, Roman Kennke wrote: > > > > > > Except that you should probably also check if the thread was > interrupted > > > > > > as the original patch does for read and write. > > > > > > > > > > I did it like that and it solved all my problems :-) > > > > > > > > But surely you have the same problem with any other callers of > > > > cpio_connect, or indeed cpio_*. You only fixed the bug in one place. > > > > > > Yeah I agree. I was wondering the same, but I decided to follow what > > > Mark did and fix it in VMChannel. Maybe should pull all these fixes into > > > javanio.c then? > > > > The only consumer is VMChannel. > > If you're going to loop around connect(2), you surely want to do so as > close to the syscall as possible. > > Now, is VMChannel supposed to be POSIX-specific or not? If it is > supposed to be POSIX-specific, and there seem to be an awful lot of > POSIXisms in there, why is it using cpio_connect() instead of simply > connect(2)? I guessed that cpio_connect() was supposed to be a > platform-independent abstraction on a syscall, but it isn't being used > to do that: VMChannel.c isn't platform-independent. So cpio_connect() > is useless, isn't it?
I agree. > > And VMChannel is the code that knows whether an interrupt should > > cause the original java method to throw an exception or not (based > > on the Thread.interrupted status). > > > > A redesign might be in order since now both java-nio and nativelib > > provide a syscall wrapper through javanio.c and cpio.c (with similar > > names, but slightly different semantics I see now). Maybe Casey and > > Guilhem could sort that out after the release. > > Mmm. Mmm. /Roman
