On 06/06/2012 00:12, Rémi Forax wrote:
Thanks Alan,
I can't ensure that the blocking mode will not change by synchronizing on
the channel's blockingLock because I will have to take the lock
before creating the reader and releasing it when the reader is closed.
Looking at now, it would need to be done in StreamDecoder.readBytes.
An easier solution is to throw an IllegalBlockingModeException
if the channel.read() returns 0, in that case I think I don't have to
even check the configured mode
(the question is what to do if the configured mode is changed by
another thread between the call to read()
and the call to isBlocking()).
It's possible that read may return bytes immediately when configured
non-blocking so it means you will need to check the blocking mode to
ensure that the expected IllegalBlockingModeException is thrown. I guess
you could also check for 0 to avoid grabbing the blocking lock.
-Alan.
