Preliminary review: Adding tracing of I/O calls

[Alan Bateman]

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();
s.setSoTimeout(5*1000);
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 
IoTraceListener.

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 
future.

-Alan.