-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jeroen Frijters wrote:
> Tom Tromey wrote:
>> Casey> - Adds a NativeFD interface to all our Channel
>> implementations that
>> Casey> returns the native file descriptor integer. The plan
>> here would be that
>> Casey> a Selector implementation could work generically given
>> that you register
>> Casey> a Channel that implements NativeFD.
>>
>> I think this is the only problematic bit. AIUI we've been careful
>> until now to keep the 'fd == int' identity hidden in the VM layer.
>> That makes it all a bit more palatable to VMs on non-posixy platforms;
>> IKVM comes to mind.
>
> Yeah, in general int handles aren't great for me, but in this case I'm
> not convinced that it's worthwhile to design a more abstract VM layer.
> Sun already designed these APIs with a provider model (like the regular
> sockets) and like the regular sockets I just replaced all of the *Impl
> classes (although for nio I also had to replace some other classes,
> which wasn't ideal I guess.)
>
> One small point regarding this though, I think it's better to move
> around references to NativeFD and do the getNativeFD call that returns
> the int as late as possible (i.e. close to the native method
> invocation). That will at least make it easier to replace NativeFD with
> another class, should anyone want to do so. And it doesn't hurt perf or
> make the code any less clear (arguably more clear).
>
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 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.
Thanks.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQEVAwUBRNhCkeRILCRAfKHCAQLWQgf/bl7TSQsJZu2IxNa2FmK+cUxbl2ETCGYR
WxjS1tWPc+NnaWkIfeK9YyqPZOT4HE5n4r+e9ftdQb+uc1bY9C+9WhS3IGEHCGNu
RjAUprE1fFUTWhgmUAHtDCbj6isMXuwCdXvAmbreeSyIMWJaApCXlZTVZa+RkW7M
cqNBw5CxUhSmgA+/7dQUiXr5tMf8QfI9ZugQKHjCysLwK7txjN2SRDWfTeMwAXgF
mV+puf7Iep2BJph8DInQ90aReAddsyAugLoZdD+ddlp2RjyIVNMkxfIvjH4n18Pl
fTsg0SVarIbHR+ck/T6oWtIkkITH4O4X69ZINqihnpJuq6Sq5VSLJg==
=MgZn
-----END PGP SIGNATURE-----
