Casey Marshall wrote:
> On reflection, it actually seems like a better idea to
> augment VMChannel
> for this purpose (and refactor VMPlainSocketImpl) instead. Right now
> VMChannel takes a Channel object, and extracts the native file
> descriptor integer, and uses it internally. Instead, each
> Channel object
> could just create a VMChannel instance, delegate its method
> calls to it,
> and in our RI we'll use native FD integers under the hood.
>
> Some of the methods I was adding to VMChannel almost support this,
> anyway, like this:
>
> > public int accept() throws IOException
> > {
> > return accept(nfd.getNativeFD());
> > }
> >
> > public static native int accept(int native_fd) throws IOException;
>
> We could instead make accept() return a new VMChannel, make the native
> method private, and in our reference implementation, use an integer
> native file descriptor. Most of the methods in VMChannel
> support this at
> least partially -- there is a plain call that doesn't use any
> descriptor
> integer, and a call that takes a FD int as an argument, and the former
> passes a private integer instance variable to the latter.
> We'd just need to make the FD ones private in the RI.
>
> Then we can add a getNativeFD() call to VMChannel, that platform
> specific code, like the kqueue Selector, can call. VMs that don't use
> integers as file descriptors can then throw
> UnsupportedOperationException for that method.
>
> Does this sound like it will work?
I think so.
> I don't know if we usually define VM
> classes as classes to be instantiated, instead of being all static
> methods, but I can't think of any drawback of doing that.
I have done that in at least one other instance (VMThread) and I think
it works well.
Regards,
Jeroen
