Preliminary review: Adding tracing of I/O calls
Alan.Bateman at oracle.com
Sun Nov 4 15:13:12 UTC 2012
On 04/11/2012 12:50, Staffan Larsen wrote:
>> I realize the focus is blocking I/O for now but one thing to know is that timed read operations on socket adapters (the socket obtained by calling SocketChannel's socket method) configures the socket channel to be non-blocking so this means that this I/O will not be observed by the IoTraceListener.
> I need some help to understand which call path you are referring to here. I see SocketChannelImpl.socket() returning a SocketAdapter, but I don't see how/if this is Socket is configured to be non-blocking.
Socket s = sc.socket();
int n = s.getInputStream().read(ba);
This read is a blocking read, it's just that the underlying socket
channel will be non-blocking so it will not be observed by the
This shouldn't be too common and might not be a big concern but I just
wanted to point it out.
>> SolarisUserDefinedFileAttributeView - this is I/O on a file's extended attributes rather than its contents, it might not interesting to the IoTraceListener.
> Hard to tell if it will be interesting or not. If there is i/o related to the file, it is probably of interest when diagnosing problems. I also don't know how to exclude this information in a simple way.
It probably isn't too interesting, I was mostly pointing out the
inconsistencies. With the current patch then IoTraceListener will see
the events on Solaris and they will look like regular I/O on the file.
On Linux then the IoTraceListener will not will be notified. On Windows
then the IoTraceListener will be notified, it's just that the file name
that it sees will name the named stream in the name. There are bigger
fish to fry so this may be something to look at again some time in the
More information about the core-libs-dev