The following blocking operations are fiber friendly in the current prototype; these methods do not pin the carrier thread when the operation blocks.
|java.net.Socket||connect, read, write||Relies on JEP 353|
|java.nio.channels.SocketChannel||connect, read, write, close||connect, read, write, and close on the socket adaptor obtained via SocketChannel::socket also okay|
|java.nio.channels.ServerSocketChannel||accept, close||accept and close on the socket adpator obtained via ServerSocketChannel::socket also okay|
|java.nio.channels.DatagramChannel||read, receive, close||write and send do not block|
The following blocking operations are not currently fiber friendly; these methods pin the carrier thread when the operation blocks.
|java.net.DatagramSocket||receive||Need to investigate if receive can be done without synchronizing on the DatagramPacket (unspecified but long standing behavior)|
getByName, getAllByName, ..
|These methods block in NSS/equivalent. Several operations to explore including using a thread pool or dusting off the JNDI DNS provider.|
|java.nio.channels.Selector||select||Selection operations are specified to synchronize on the selector and the selected-key set. May not be a concern as code using fibers should not need to use non-blocking I/O and Selectors.|
|java.lang.Thread||interrupt||If a thread is interrupted when blocked in an I/O operation on an InterruptibleChannel then the channel is closed. The locking to support this is not yet fiber friendly so Thread.interrupt may pin the carrier thread while waiting for the blocking operations on the channel to abort. This should resolved itself once close is changed to non-blocking.|