Re: java.net: Classpath vs. libgcj Comparison

[Bryce McKinlay <bryce at albatross dot co dot nz>]

Tom Tromey wrote:

> >>>>> "Jeff" == Jeff Sturm <jsturm@sigma6.com> writes:
>
> Jeff> Also, java.net.SocketInputStream and SocketOutputStream are
> Jeff> classes I was going to propose for libgcj, since the current
> Jeff> assumption that sockets can be represented by FileDescriptors
> Jeff> just isn't portable (win32 at least has a completely separate
> Jeff> API for socket I/O).
>
> It seems like we'd have to hide this underneath FileDescriptor.
> E.g., add a flag and have the Windows implementation switch calls at
> runtime.

Currently we dont implement Socket.setTimeOut() (SO_TIMEOUT) for socket
read() calls. We can implement this using select(), but it can't be done
inside natFileDescriptor because at that point we don't know if its a
socket or an ordinary file, and don't have access to the socket flags
anyway. When I was looking at this a while ago I came to the conclusion
that we do in fact need to have seperate outputstream code for Files and
Sockets, at least at some level. The problem of File descriptors not
being a portable way to represent sockets seems to add weight to this.

regards

  [ bryce ]