Casey Marshall writes: > On Dec 5, 2006, at 2:52 AM, Andrew Haley wrote: > > The cpnio functions are (should be) trivial and inlined. > What more is needed?
> > Now, is VMChannel supposed to be POSIX-specific or not? If it is > > Yes, 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? > > No. This was trying to address the issues VM implementors had when > it comes to user-space threads: syscalls that we use that can block > indefinitely are wrapped in an easy-to-replace implementation, but > otherwise the code assumes a POSIXy system. > > We went through this before. It seems that I didn't, anyway. > I thought we had enough of a consensus that POSIX was a good enough > abstraction for our reference implementation of the native code, as > long as we left hooks like this in place for VMs when it comes to > blocking IO calls. You'll notice that we don't do this for other > functions that (according to the documentation) won't block. OH, OK. You are quite right: there is an explanation of this in javanio.h. So let me understand: this is to support a user-space threads package that requires special handling of blocking syscalls, perhaps one that doesn't provide wrappers for connect() _et al_. And although these functions don't look like they will be inlined, they will because CPNIO_EXPORT is #defined "static inline" and javanio.c is #included by javanio.h. > Maybe I'm mistaken here. I'd like to hear opinions again from VM > implementors on how well the cpnio stuff works for them. I think > JikesRVM and Kaffe were the ones that offered user-space threading. > > native/jni/java-nio/javanio.h explains all of this. Andrew.
