Would you mind raising a jira[1] for it? So we can track it.It would be better if you can provide us a small testcase to reproduce it. Someone of our community will take a look at for you.
And thank you for your contributing to Harmony. It is appreciated very much. [1] http://issues.apache.org/jira/browse/HARMONY 2009/1/13 Hui Ding <[email protected]> > Hi Experts, > I am writing an application with NIO and Selector and found a strange > issue that if I call "Selector.close()" while a thread is being > blocked on that Selector(By calling "Selector.select()"), the call to > "close()" will block indefinitely until "Selector.select()" returns. > It's said in the Javadoc of selector.close() that: "If a thread is > currently blocked in one of this selector's selection methods then it > is interrupted as if by invoking the selector's wakeup method". So I > guess under no circumstances should Select.close() block, right? > However I came across another topic about the concurrency of Selector: > "The selection operations synchronize on the selector itself, on the > key set, and on the selected-key set, in that order. > The close method synchronizes on the selector and all three key sets > in the same order as in a selection operation." If it is true that > Selector.select() and Selector.close() both synchronize on the > selector itself, I think Selector.close() will block if other threads > are blocked on Selector.select(). > > Now I am confused about which one is the correct behavior of > Selector.close(), blocking or not? > > BTW. I gave it a try on a Desktop PC with SUN JDK and Harmony JDK, seems > with SUN JDK, Selector.close() will never block while with Harmony > JDK, if another thread is being blocked on Selector.select(), > Selector.close will block until select() returns. Is this a bug with > Harmony JDK or not? > -- Best Regards Sean, Xiao Xia Qiu China Software Development Lab, IBM
