non-blocking channel Infinite loop in java.util.Scanner

Alan Bateman Alan.Bateman at
Wed Jun 6 10:08:00 UTC 2012

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


More information about the core-libs-dev mailing list