On Dec 6, 2006, at 4:01 AM, Andrew Haley wrote:
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.
Some of us may have discussed some of this on IRC/off list. I don't
remember.
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_.
Yup. I seem to recall e.g. JikesRVM doing some LD_PRELOAD hackery to
intercept blocking system calls. This should make that unnecessary,
since all they need to do now is provide a different version of the
cpnio_* functions.
I would have preferred to simply omit the cpnio_* bits in the NIO
changes I made, but a sufficient number of people did complain that
this would not work well for green threaded VMs.
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.
Yeah. Maybe the macro name isn't great, but in Classpath's version,
it should be defined to inline those functions, since they're
trivial. If some VM needed a more complicated implementation, they
can #define CPNIO_EXPORT to be empty.
Thanks.
