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.
