Name: diC59631 Date: 05/27/98


We propose that two new methods be added to the
DatagramSocketImpl class.

1) A class constructor that accepts a FileDescriptor parameter:

     public DatagramSocketImpl(FileDescriptor fd);

2) A class method to block until data is available for reading:

     public block_until_avail(); // or other name

 
A class constructor that accepts a FileDescriptor parameter:
------------------------------------------------------------

The new constructor would enable programmers to extend the socket
class more readily. For example, one could to extend the socket class
to read and write raw IP packets. A derived socket class could open
and initialize a kernel socket in a specialized way and complete the
construction of a Java socket object by calling the base class
constructor given a FileDescriptor object.

The current JDK API does not allow programmers to implement more
advanced socket i/o. Currently there is no mechanism to tell the JVM
which file descriptors have been opened for reading (when the
descriptors have been opened by native methods for example).
Surely the JVM must know which descriptors have been opened so that the
corresponding thread can be woken up? (We have submitted an
alternative solution via the JDC, entitled "Require extension of
JNI interface", jre # 4132800).

It would also be useful to have a way to create a FileDescriptor object
in a native method using JNI support.


block_until_available(): A blocking version of available():
-----------------------------------------------------------

The semantics of this method would be similar to available() except that
the method would block until data is available for reading instead of
returning zero. If data is available for reading then the method returns
the number of bytes available. This would allow programs to build methods
that have similar semantics to the blocking read() method.

Currently, this is difficult to implement, even if one chooses to use
the JNI. The Sun implementation of the JVM uses the synchronization
constructs --- sysMonitorEnter, sysMonitorWait and sysMonitorExit--- to
synchronize the waiting thread with the arrival of a packet. However,
these constructs are not exported via the JNI interface. Our current
implementation of this method does not work on different JVM
implementations for this reason.


Graham Phillips <###@###.###>
Bob Braden <###@###.###>
Bob Lindell <###@###.###>
(Review ID: 29976)
======================================================================