Rangi Keen created NETBEANS-1834:
------------------------------------
Summary: Possible race condition in ExplorerActionsImpl
Key: NETBEANS-1834
URL: https://issues.apache.org/jira/browse/NETBEANS-1834
Project: NetBeans
Issue Type: Bug
Components: platform - Explorer
Affects Versions: 8.2
Reporter: Rangi Keen
Attachments: ExplorerActionsImpl.Race.patch
{{ExplorerActionsImpl}} uses a background thread to determine the enabled state
of its actions. The background thread calls
{{ExplorerActionsImpl.BaseAction.toEnabled(boolean)}} to set the target state
from the background thread and then queues up a call on the {{EventQueue}} to
be run on the EDT that calls {{ExplorerActionsImpl.BaseAction.syncEnable()}}
which calls {{setEnabled}} if {{toEnable}} is non-null.
However, since the check for {{toEnable != null}}, the use of {{toEnable}} in
the call to {{setEnabled}}, and the set of {{toEnable = null}} are all on
separate lines there is the possibility that another call to
{{toEnabled(boolean)}} will set {{toEnable}} after the call to {{setEnabled}}
but before it is reset to null. The end result is that if the new value of
{{toEnable}} was different from the one being acted upon, the action may end up
in the wrong state.
One solution (in [^ExplorerActionsImpl.Race.patch]) is to use an
{{AtomicInteger}} to get the value of {{toEnable}} and set it to null (or
{{NO_CHANGE}}) atomically, thus avoiding the race condition.
I don't have a reproducible case in the NetBeans IDE, but we encountered this
in our custom application using the NetBeans platform. The attached patch
solved the issue in our case.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
