RE: FileDescriptor proposal

[Jeroen Frijters]

Anthony Green wrote:
> The same must be true for GNU Classpath, since it provides an 
> "int" file descriptor to its users to operate on.  How does 
> IKVM work, because I don't see a replacement for 
> FileInputStream?  Surely you need one.

Have you looked at the most recent GNU Classpath FileDescriptor? It
fully encapsulates the file descriptor (apart from getNativeFd used by
java.nio.*, but I'm ignoring that at the moment).

> It looks like you 
> have non-native methods on FileDescriptor for the low level 
> operations which, in turn, call your IKVM system.io classes. 

This is correct, except that the system.io classes aren't mine they are
part of the underlying platform.

> libgcj could work this way also, so non-native FileDescriptor 
> methods call the underlying native methods.  This would 
> isolate all of the
> platform specific changes in this one class, which would be 
> good.   The
> advantage of my scheme, however, is that it replaces two 
> non-virtual method calls with a single virtual call.  It also 
> won't cause problems down the road if we introduce 
> cross-module inlining in gcj.

I'm not sure that two non-virtual calls is worse than a single virtual
call. Inlining two non-virtual calls is definitely easier than inlining
a single virtual call.

> Another advantage of my scheme is that FileDescriptor.getPFD 
> can provide stream specific implementations of 
> PlatformFileDescriptor.  For instance, my System.out 
> PlatformFileDescriptor can immediately do the right thing for 
> my target, rather than rely on yet another level of 
> indirection in the underlying IO system.  This is something 
> I'd really like to do.

OK. I can see the advantage of this.

> Forking bits of libgcj/Classpath also seems wrong and unnecessary.

Agreed, but I'm pretty sure that the current model only requires you to
replace FileDescriptor.

Regards,
Jeroen