FileDescriptor proposal

Fri Apr 18 08:26:00 GMT 2003

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