JDK-8054039 Deadlock during interrupting FileChannel

[Brian Burkhalter]

Hi Frank,

On Sep 9, 2015, at 12:59 AM, Frank Yuan <frank.yuan at oracle.com> wrote:

> Thank you for review and your comments:)

You are welcome.

> The size of my last mail is too large, is still held by maillist moderator, I have to send some content again(the diagram still can't be attached…).

You could upload the diagram and a webrev to cr.openjdk.java.net assuming you have an ID. If not, I could do it for you.

> I am suspicious of the use of reflection here.
> I also have some concern for this solution, because in this fix nio will depend on the private method of Thread -- interrupt0, it will break the encapsulation. However it's an available solution in theory.

True but I think the second one is better.

> Within the scope of AbstractInterruptibleChannel I do not see any problem with the change that you propose. Given that the affected instance variables are private to the class and that AtomicBoolean “generally” follows the rules for volatiles it looks conceptually valid. I do not know however about the implications with respect to interactions with other classes. For example, could this change provoke some unforeseen behavior as a result of subtle changes in timing?
>  
> As my understood, this solution won't spend more time on begin() than the old code, compareAndSet is atomic and there is no loop or wait. Anyway I am not sure your concern, will do more tests, hope more people can review it.

Indeed I don’t know whether there would be any effect: it was simply an observation. I expect others will comment when they have time.

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20150909/2c8f2621/attachment.html>