bug-classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug classpath/86154] New: Incorrect implementation of Selector.wakeup()


From: guillerodriguez.dev at gmail dot com
Subject: [Bug classpath/86154] New: Incorrect implementation of Selector.wakeup()
Date: Thu, 14 Jun 2018 14:53:26 +0000

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86154

            Bug ID: 86154
           Summary: Incorrect implementation of Selector.wakeup()
           Product: classpath
           Version: 0.99
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: classpath
          Assignee: unassigned at gcc dot gnu.org
          Reporter: guillerodriguez.dev at gmail dot com
  Target Milestone: ---

Created attachment 44275
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44275&action=edit
Test case

In GNU Classpath, Selector.wakeup() internally calls Thread.interrupt() in
order to awake a thread that is blocked in select(), then immediately call
Thread.interrupted() to clear the 'interrupted' flag.

There are several issue with this:

 1. This violates the API contract for Selector.wakeup() which says: "If no
selection operation is currently in progress then the next invocation of one of
these methods will return immediately unless the selectNow() method is invoked
in the meantime." With the current implementation, a call to Selector.wakeup()
will have no effect if there is no selection operation currently in progress.

 2. Because the current implementation temporarily sets the thread
'interrupted' flag and then clears it again, this may break applications which
(correctly) do not expect that a thread may be "interrupted" by the class
libraries. One such application is the Java websockets server from
https://github.com/TooTallNate/Java-WebSocket.

This problem affects all three Selector implementations in GNU Classpath
(gnu.java.nio.SelectorImpl, gnu.java.nio.EpollSelectorImpl,
gnu.java.nio.KqueueSelectorImpl)

A test case that can be used to reproduce problem #1 is attached.

On OpenJDK this shows the following and exits:

===
before select
after select
===

On GNU Classpath this shows the following and does not exit:

===
before select
===


reply via email to

[Prev in Thread] Current Thread [Next in Thread]