Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4142968

DatagramSocketImpl extension request

    XMLWordPrintable

    Details

    • Subcomponent:
    • CPU:
      sparc
    • OS:
      solaris_2.5.1

      Description

      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)
      ======================================================================

        Attachments

          Activity

            People

            Assignee:
            jccollet Jean-Christophe Collet (Inactive)
            Reporter:
            dindrigo Daniel Indrigo (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: