This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 181065 - remove EDT-only restriction of Term IO Provider
Summary: remove EDT-only restriction of Term IO Provider
Status: RESOLVED FIXED
Alias: None
Product: cnd
Classification: Unclassified
Component: Terminalemulator (show other bugs)
Version: 6.x
Hardware: All All
: P2 normal (vote)
Assignee: ivan
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-02-22 23:44 UTC by Vladimir Voskresensky
Modified: 2010-06-17 10:42 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Vladimir Voskresensky 2010-02-22 23:44:32 UTC
must be no "EDT-only" restriction for client's call
IOProvider().get("Terminal").getIO

default IO does not have such restriction.

java.lang.IllegalStateException: Problem in some module which uses Window System: Window System API is required to be called from AWT thread only, see http://core.netbeans.org/proposals/threading/
	at org.netbeans.core.windows.WindowManagerImpl.warnIfNotInEDT(WindowManagerImpl.java:1517)
	at org.netbeans.core.windows.WindowManagerImpl.topComponentID(WindowManagerImpl.java:1212)
	at org.openide.windows.WindowManager.findTopComponentID(WindowManager.java:527)
	at org.netbeans.core.windows.model.TopComponentSubModel.getID(TopComponentSubModel.java:364)
	at org.netbeans.core.windows.model.TopComponentSubModel.containsTopComponent(TopComponentSubModel.java:260)
	at org.netbeans.core.windows.model.DefaultModeModel.containsTopComponent(DefaultModeModel.java:260)
	at org.netbeans.core.windows.model.DefaultModel.containsModeTopComponent(DefaultModel.java:818)
	at org.netbeans.core.windows.Central.containsModeTopComponent(Central.java:1496)
	at org.netbeans.core.windows.ModeImpl.containsTopComponent(ModeImpl.java:384)
	at org.netbeans.core.windows.WindowManagerImpl.findMode(WindowManagerImpl.java:439)
	at org.netbeans.core.windows.WindowManagerImpl.getMode(WindowManagerImpl.java:1350)
	at org.netbeans.core.windows.WindowManagerImpl.topComponentOpenAtTabPosition(WindowManagerImpl.java:1059)
	at org.netbeans.core.windows.WindowManagerImpl.topComponentOpen(WindowManagerImpl.java:1047)
	at org.openide.windows.TopComponent.open(TopComponent.java:488)
	at org.openide.windows.TopComponent.open(TopComponent.java:468)
	at org.netbeans.core.io.ui.IOWindow$IOWindowImpl.open(IOWindow.java:274)
	at org.netbeans.core.io.ui.IOWindow.open(IOWindow.java:109)
	at org.openide.windows.IOContainer.open(IOContainer.java:114)
	at org.netbeans.modules.dlight.terminal.Terminal.<init>(Terminal.java:186)
	at org.netbeans.modules.dlight.terminal.TerminalProvider.createTerminal(TerminalProvider.java:91)
	at org.netbeans.modules.dlight.terminal.TerminalInputOutput.<init>(TerminalInputOutput.java:381)
	at org.netbeans.modules.dlight.terminal.TerminalIOProvider.getIO(TerminalIOProvider.java:57)
	at org.netbeans.modules.cnd.makeproject.api.ProjectActionSupport$HandleEvents.getTermIO(ProjectActionSupport.java:306)
	at org.netbeans.modules.cnd.makeproject.api.ProjectActionSupport$HandleEvents.go(ProjectActionSupport.java:387)
	at org.netbeans.modules.cnd.makeproject.api.ProjectActionSupport$HandleEvents.access$000(ProjectActionSupport.java:165)
[catch] at org.netbeans.modules.cnd.makeproject.api.ProjectActionSupport$HandleEvents$6.run(ProjectActionSupport.java:479)
	at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:641)
	at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:1123)
WARNING [org.netbeans.core.windows.WindowManagerImpl]
Comment 1 Vladimir Voskresensky 2010-02-22 23:45:58 UTC
for now have to use SwingUtilities.invokeAndWait hack to get term io
Comment 2 Quality Engineering 2010-03-02 22:09:20 UTC
Integrated into 'main-golden', will be available in build *201003030200* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/a212649fc9bc
User: ivan@netbeans.org
Log: bug #181065 improve and clean up the comprehensive test dialog/action
Comment 3 ivan 2010-05-05 07:50:15 UTC
Changeset: http://hg.netbeans.org/main/rev/f14b3a4eb445

    InputOutput methods are supposed to be callable on any thread.
    If they manipulate Swing components, and especially if they
    interact with the IOContainer, the actual work has to be done on the EDT.
    To that end we have a 'Task' system that schedules Tasks on the EDT.
    This is an analog of output2's Controller/IOEvent subsystem.
    So, part of this task is to ensure that all requests have a corresponding
    Task and are performed on the EDT.

    To that end ...
    - Introduced Task.Scroll and Task.SetClosable.
    - If all appropriate requests are properly relegated to the EDT via
      Tasks then TerminalContainerImpl.removeTab() need not do an
      isEventDispatchThread() check.

    Additionally, Term, being a Swing component should only be accessed
    on the EDT. We'll try and adopt the general rule that methods on
    TerminalInputOutput can be called on any thread and if it needs to
    alter the state of a Term a Task will be used. The Task, in turn,
    will call methods of Terminal which are EDT-only methods.

    To that end ...
    - Approached this problem by working towards the elimination of all
      Term access in TerminalInputOutput. This drives us to delegate
      accesses to Term via the Task system and Terminal. As a result
      various functionality, especially listener registration and
      deregistration, migrated to Terminal.
    - Introduced Task.SetDisciplined, Task.SetCustomColor, Task.ClearHistory,
      Task.Connect, Task.Disconnect, Task.BeginActiveRegion and
      Task.EndActiveRegion.
    - Introduced a Variation on Task which doesn't take a container
      as an argument in order to support Term-only accesses.
    - IOColor and other color changes don't work via the Term setAttributes()
      API anymore. Rather, they send the relevant ANSI sequences via getOut().
      TerminalInputOutput.setColor() is the utility to support this.
    - Our OutputWriter implementation in StreamTerm would blindly access
      Term.putChars(). Now it trampolines through an invokeAndWait().
    - Do deal with methods that return a value introduced Task.ValueTask
      which gets the value on the EDT and uses futures to transfer then
      to the original caller. The following tasks are ValueTasks:
      GetPosition, GetIn and GetOut.

    Certain methods on InputOutput, if they are not already invoked on the EDT,
    will now "block" waiting for the EDT in that they will use
    invokeAndWait() or wait for a future which is set on the EDT.

    Incidental:
    - Switched to using ActiveTerm all over instead of the ad-hoc mixture of
      instanceof tests and casts.
    - Mutexed the creation of getOut() and getErr(). This has nothing to
      do with the above ... just aping output2.
    - Added T5_MTStress_Test.
    - The implementation of sleep() in TestSupport which was based
      on counting outstanding Tasks (via IOTEst.isQuiesent()) turns
      out not to work with multiple threads.
      Instead will just use invokeAndWait() to hold until all prior
      submitted Tasks clear.
    ! The common failure of the T1_Close_Test was because of the disconnect
      continuation which runs on a dedicated thread, not EDT.
      So now TestSupport provides a dummy Runnable which sets a flag
      which is checked by sleep.