It does sound like the best thing to do would be for the QuitProgram plugin to post (= publishLater) a quit event that could be subscribed by something deeper inside scijava. Perhaps two events are needed - a QuitVeto event that is published and that can be vetoed by any subscribers (e.g - a script editor with an unsaved script) and, once everyone has committed to quitting, the actual Quit event which can be posted and handled in the event thread.
On Thu, Oct 17, 2013 at 3:03 PM, Barry DeZonia <bdezo...@gmail.com> wrote: > Still I guess that the thread running the QuitProgram plugin will always > still be running while QuitProgram is disposing the context. So in addition > maybe the context dispose code should be like a time bomb that is set, the > QuitProgram plugin completes, and then the bomb goes off shutting all > services down. > > > On Thu, Oct 17, 2013 at 2:00 PM, Barry DeZonia <bdezo...@gmail.com> wrote: > >> I think that we should not need to make these changes. Curtis is right in >> that the services should shut down in an orderly fashion. I think the real >> problem is the services aren't shutting down in an expected order. One can >> print which services are getting disposed in what order and can see that >> they are nowhere near to the original initialization order. The >> ThreadService is terminating very early and then active threads associated >> with its executor become invalid. The ThreadService should be one of the >> last things to dispose but it is one of the first. >> >> >> On Wed, Oct 16, 2013 at 3:53 PM, Curtis Rueden <ctrue...@wisc.edu> wrote: >> >>> > I could implement Curtis's suggestion and mark the status service as >>> > closed after dispatch >>> >>> Well, intuitively, the EventService, StatusService, ThreadService, etc., >>> once dispose() is called on them, shouldn't be hanging around anywhere >>> else. That is, any services that use them should have already been disposed >>> too, and no longer trying to publish anything. So something seems fishy to >>> me here. But I admit I have spent zero time looking into it. >>> >>> -Curtis >>> >>> >>> On Wed, Oct 16, 2013 at 3:43 PM, Lee Kamentsky >>> <l...@broadinstitute.org>wrote: >>> >>>> Strange, I've cherrypicked the patch to my master branch of >>>> scijava-common and have successfully run it against the master branch of >>>> imagej and I don't see your error message when I close. >>>> >>>> The patch is general and solves the case where you open a sample image >>>> and close - both cases catch the error. I could implement Curtis's >>>> suggestion and mark the status service as closed after dispatch - that's >>>> probably the correct way to do it, but this is pretty robust and does >>>> something useful with status messages sent during shutdown. >>>> >>>> >>>> On Wed, Oct 16, 2013 at 4:25 PM, Barry DeZonia <bdezo...@gmail.com>wrote: >>>> >>>>> Lee, >>>>> >>>>> Using your patch I have an error. Open program and exit and I get this: >>>>> >>>>> java.lang.IllegalStateException: Context already injected: >>>>> org.scijava.AbstractContextual#context >>>>> >>>>> at org.scijava.Context.inject(Context.java:281) >>>>> >>>>> at org.scijava.AbstractContextual.setContext( >>>>> AbstractContextual.java:66) >>>>> >>>>> at org.scijava.event.DefaultEventService.publishLater( >>>>> DefaultEventService.java:100) >>>>> >>>>> at org.scijava.app.DefaultStatusService.publish( >>>>> DefaultStatusService.java:123) >>>>> >>>>> at org.scijava.app.DefaultStatusService.showStatus( >>>>> DefaultStatusService.java:76) >>>>> >>>>> at imagej.module.ModuleRunner.run(ModuleRunner.java:155) >>>>> >>>>> at imagej.module.ModuleRunner.call(ModuleRunner.java:129) >>>>> >>>>> at imagej.module.ModuleRunner.call(ModuleRunner.java:1) >>>>> >>>>> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) >>>>> >>>>> at java.util.concurrent.FutureTask.run(FutureTask.java:138) >>>>> >>>>> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask( >>>>> ThreadPoolExecutor.java:895) >>>>> >>>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run( >>>>> ThreadPoolExecutor.java:918) >>>>> >>>>> at java.lang.Thread.run(Thread.java:680) >>>>> >>>>> >>>>> Plus said patch will not affect the open sample image and then exit >>>>> crashes. But that may need to be filed as a separate bug. >>>>> >>>>> >>>>> On Wed, Oct 16, 2013 at 3:04 PM, Lee Kamentsky < >>>>> l...@broadinstitute.org> wrote: >>>>> >>>>>> Maybe I wasn't patient enough about refreshing everything.... will >>>>>> submit patch momentarily, but have only tested it on a modified version >>>>>> of >>>>>> the scijava-common-2.2.0 branch. I'd appreciate you merging and trying >>>>>> it. >>>>>> >>>>>> >>>>>> On Wed, Oct 16, 2013 at 3:54 PM, Barry DeZonia <bdezo...@gmail.com>wrote: >>>>>> >>>>>>> In imagej/pom.xml I added: >>>>>>> >>>>>>> <scijava-common.version>2.2.1-SNAPSHOT</scijava-common.version> >>>>>>> >>>>>>> in the <properties> section >>>>>>> >>>>>>> >>>>>>> On Wed, Oct 16, 2013 at 2:46 PM, Lee Kamentsky < >>>>>>> l...@broadinstitute.org> wrote: >>>>>>> >>>>>>>> Are you editing one of the POMs to pick up the 2.2.1-SNAPSHOT >>>>>>>> version of scijava-common? >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Oct 16, 2013 at 3:45 PM, Barry DeZonia >>>>>>>> <bdezo...@gmail.com>wrote: >>>>>>>> >>>>>>>>> I'm not having any problems building scijava-common master against >>>>>>>>> IJ2 master. >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Oct 16, 2013 at 2:25 PM, Lee Kamentsky < >>>>>>>>> l...@broadinstitute.org> wrote: >>>>>>>>> >>>>>>>>>> I have a very simple fix in scijava-common, but it seems that the >>>>>>>>>> head of the scijava-common master branch is not going to build with >>>>>>>>>> the >>>>>>>>>> head of the imagej master branch. How should I proceed? I could >>>>>>>>>> branch off >>>>>>>>>> off scijava-common-2.2.0 I suppose. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, Oct 16, 2013 at 2:44 PM, Barry DeZonia < >>>>>>>>>> bdezo...@gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> Thanks. I also updated the ticket a bit a few minutes ago. In my >>>>>>>>>>> second example problem (closing app with sample image open) it >>>>>>>>>>> looks like >>>>>>>>>>> the original open samples legacy command was not finishing its run. >>>>>>>>>>> Not >>>>>>>>>>> sure if this is related to your event processing changes. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Wed, Oct 16, 2013 at 1:19 PM, Lee Kamentsky < >>>>>>>>>>> l...@broadinstitute.org> wrote: >>>>>>>>>>> >>>>>>>>>>>> Sorry, I missed it. I'll see if I can take a look at it, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Oct 16, 2013 at 2:15 PM, Barry DeZonia < >>>>>>>>>>>> bdezo...@gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Lee did you see I reopened ticket #1992 ( >>>>>>>>>>>>> http://trac.imagej.net/ticket/1992) that was related to this >>>>>>>>>>>>> code change? >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Mon, Oct 7, 2013 at 10:15 AM, Barry DeZonia < >>>>>>>>>>>>> bdezo...@gmail.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Merged >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Mon, Sep 30, 2013 at 2:34 PM, Lee Kamentsky < >>>>>>>>>>>>>> l...@broadinstitute.org> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> I submitted a patch to scijava-common with the changes. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> https://github.com/scijava/scijava-common/pull/13 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Mon, Sep 30, 2013 at 3:32 PM, Barry DeZonia < >>>>>>>>>>>>>>> bdezo...@gmail.com> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> A proposed fix would be good Lee. I'd like to test the >>>>>>>>>>>>>>>> async status update code for responsiveness (i.e. when opening >>>>>>>>>>>>>>>> a large >>>>>>>>>>>>>>>> image let's say). Let me know when your fix is in place. >>>>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Fri, Sep 27, 2013 at 6:54 AM, Lee Kamentsky < >>>>>>>>>>>>>>>> l...@broadinstitute.org> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks Barry, the email was a little rushed - finished it >>>>>>>>>>>>>>>>> while going out the door. What do you think about sending the >>>>>>>>>>>>>>>>> status >>>>>>>>>>>>>>>>> messages asynchronously? It looks to me like the AWT event >>>>>>>>>>>>>>>>> processing will >>>>>>>>>>>>>>>>> display them in the order received, so that makes sure that a >>>>>>>>>>>>>>>>> "Finished" >>>>>>>>>>>>>>>>> message will be seen after a "% complete" message. Status >>>>>>>>>>>>>>>>> reporting is such >>>>>>>>>>>>>>>>> a common thing - it'd be a shame for all the worker threads >>>>>>>>>>>>>>>>> to stall >>>>>>>>>>>>>>>>> because a user was using ImageJ to watch a movie of a cat >>>>>>>>>>>>>>>>> falling off a TV >>>>>>>>>>>>>>>>> while their batch job was running. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I think I'll submit a patch to DefaultStatusService for >>>>>>>>>>>>>>>>> asynch reporting and maybe Curtis or you could look it over >>>>>>>>>>>>>>>>> and accept it. >>>>>>>>>>>>>>>>> If you reject, NP. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> --Lee >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Thu, Sep 26, 2013 at 7:53 PM, Barry DeZonia < >>>>>>>>>>>>>>>>> bdezo...@gmail.com> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Hi Lee, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I added the synchronized keyword yesterday to fix a bug. >>>>>>>>>>>>>>>>>> We can undo that change. I can work around the problem in >>>>>>>>>>>>>>>>>> another fashion >>>>>>>>>>>>>>>>>> if necessary. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Thu, Sep 26, 2013 at 3:57 PM, Lee Kamentsky < >>>>>>>>>>>>>>>>>> l...@broadinstitute.org> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Hi all, I'm getting a deadly embrace that happens when >>>>>>>>>>>>>>>>>>> the AWT event queue thread tries to get a lock within >>>>>>>>>>>>>>>>>>> DefaultDatasetView.getColor and when >>>>>>>>>>>>>>>>>>> DefaultStatusService.showStatus on a >>>>>>>>>>>>>>>>>>> worker thread tries to publish a synchronous request for >>>>>>>>>>>>>>>>>>> status display >>>>>>>>>>>>>>>>>>> after taking the DefaultDatasetView's lock in >>>>>>>>>>>>>>>>>>> DefaultDatasetView.rebuild. >>>>>>>>>>>>>>>>>>> It happens periodically, but it's timing-dependent, so not >>>>>>>>>>>>>>>>>>> so reproducible. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> The bug is somewhat debatable. Possible candidates: It's >>>>>>>>>>>>>>>>>>> a little drastic for DefaultDatasetView.getColor to >>>>>>>>>>>>>>>>>>> synchronize on the view >>>>>>>>>>>>>>>>>>> itself. Maybe some proxy for the color system could have a >>>>>>>>>>>>>>>>>>> synchronizing >>>>>>>>>>>>>>>>>>> object. The other candidate is >>>>>>>>>>>>>>>>>>> DefaultEventService.showStatus which could >>>>>>>>>>>>>>>>>>> use EventService.publishLater - I don't think there's much >>>>>>>>>>>>>>>>>>> need for status >>>>>>>>>>>>>>>>>>> publishers to wait around for the status to show on the >>>>>>>>>>>>>>>>>>> screen. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> The two stack traces: >>>>>>>>>>>>>>>>>>> Thread [AWT-EventQueue-0] (Suspended) >>>>>>>>>>>>>>>>>>> DefaultDatasetView.getColor(ChannelCollection) line: 261 >>>>>>>>>>>>>>>>>>> Synchronized >>>>>>>>>>>>>>>>>>> method on DefaultDatasetView >>>>>>>>>>>>>>>>>>> FgColorTool(AbstractColorTool).drawIcon() line: 175 >>>>>>>>>>>>>>>>>>> FgColorTool(AbstractColorTool).onEvent(DisplayActivatedEvent) >>>>>>>>>>>>>>>>>>> line: 184 >>>>>>>>>>>>>>>>>>> NativeMethodAccessorImpl.invoke0(Method, Object, >>>>>>>>>>>>>>>>>>> Object[]) line: not available [native method] >>>>>>>>>>>>>>>>>>> NativeMethodAccessorImpl.invoke(Object, Object[]) line: >>>>>>>>>>>>>>>>>>> 39 >>>>>>>>>>>>>>>>>>> DelegatingMethodAccessorImpl.invoke(Object, Object[]) >>>>>>>>>>>>>>>>>>> line: 25 >>>>>>>>>>>>>>>>>>> Method.invoke(Object, Object...) line: 597 >>>>>>>>>>>>>>>>>>> DefaultEventService$ProxySubscriber<E>.onEvent(E) >>>>>>>>>>>>>>>>>>> line: 282 >>>>>>>>>>>>>>>>>>> DefaultEventService$ProxySubscriber<E>.onEvent(Object) >>>>>>>>>>>>>>>>>>> line: 1 >>>>>>>>>>>>>>>>>>> DefaultEventBus(ThreadSafeEventService).publish(Object, >>>>>>>>>>>>>>>>>>> String, Object, List, List, StackTraceElement[]) line: 971 >>>>>>>>>>>>>>>>>>> DefaultEventBus.access$1(DefaultEventBus, Object, >>>>>>>>>>>>>>>>>>> String, Object, List, List, StackTraceElement[]) line: 1 >>>>>>>>>>>>>>>>>>> DefaultEventBus$1.run() line: 201 >>>>>>>>>>>>>>>>>>> DefaultThreadService.invoke(Runnable) line: 91 >>>>>>>>>>>>>>>>>>> DefaultEventBus.publishNow(Object, String, Object, List, >>>>>>>>>>>>>>>>>>> List, StackTraceElement[]) line: 195 >>>>>>>>>>>>>>>>>>> DefaultEventBus.publishNow(Object) line: 86 >>>>>>>>>>>>>>>>>>> DefaultEventService.publish(E) line: 95 >>>>>>>>>>>>>>>>>>> DefaultDisplayService.setActiveDisplay(Display<?>) >>>>>>>>>>>>>>>>>>> line: 129 >>>>>>>>>>>>>>>>>>> DefaultDisplayService.onEvent(WinActivatedEvent) line: >>>>>>>>>>>>>>>>>>> 247 >>>>>>>>>>>>>>>>>>> NativeMethodAccessorImpl.invoke0(Method, Object, >>>>>>>>>>>>>>>>>>> Object[]) line: not available [native method] >>>>>>>>>>>>>>>>>>> NativeMethodAccessorImpl.invoke(Object, Object[]) line: >>>>>>>>>>>>>>>>>>> 39 >>>>>>>>>>>>>>>>>>> DelegatingMethodAccessorImpl.invoke(Object, Object[]) >>>>>>>>>>>>>>>>>>> line: 25 >>>>>>>>>>>>>>>>>>> Method.invoke(Object, Object...) line: 597 >>>>>>>>>>>>>>>>>>> DefaultEventService$ProxySubscriber<E>.onEvent(E) >>>>>>>>>>>>>>>>>>> line: 282 >>>>>>>>>>>>>>>>>>> DefaultEventService$ProxySubscriber<E>.onEvent(Object) >>>>>>>>>>>>>>>>>>> line: 1 >>>>>>>>>>>>>>>>>>> DefaultEventBus(ThreadSafeEventService).publish(Object, >>>>>>>>>>>>>>>>>>> String, Object, List, List, StackTraceElement[]) line: 971 >>>>>>>>>>>>>>>>>>> DefaultEventBus.access$1(DefaultEventBus, Object, >>>>>>>>>>>>>>>>>>> String, Object, List, List, StackTraceElement[]) line: 1 >>>>>>>>>>>>>>>>>>> DefaultEventBus$1.run() line: 201 >>>>>>>>>>>>>>>>>>> DefaultThreadService.invoke(Runnable) line: 91 >>>>>>>>>>>>>>>>>>> DefaultEventBus.publishNow(Object, String, Object, List, >>>>>>>>>>>>>>>>>>> List, StackTraceElement[]) line: 195 >>>>>>>>>>>>>>>>>>> DefaultEventBus.publishNow(Object) line: 86 >>>>>>>>>>>>>>>>>>> DefaultEventService.publish(E) line: 95 >>>>>>>>>>>>>>>>>>> AWTWindowEventDispatcher.windowActivated(WindowEvent) >>>>>>>>>>>>>>>>>>> line: 94 >>>>>>>>>>>>>>>>>>> SwingDisplayWindow(Window).processWindowEvent(WindowEvent) >>>>>>>>>>>>>>>>>>> line: 1877 >>>>>>>>>>>>>>>>>>> SwingDisplayWindow(JFrame).processWindowEvent(WindowEvent) >>>>>>>>>>>>>>>>>>> line: 274 >>>>>>>>>>>>>>>>>>> SwingDisplayWindow(Window).processEvent(AWTEvent) line: >>>>>>>>>>>>>>>>>>> 1823 >>>>>>>>>>>>>>>>>>> SwingDisplayWindow(Component).dispatchEventImpl(AWTEvent) >>>>>>>>>>>>>>>>>>> line: 4630 >>>>>>>>>>>>>>>>>>> SwingDisplayWindow(Container).dispatchEventImpl(AWTEvent) >>>>>>>>>>>>>>>>>>> line: 2099 >>>>>>>>>>>>>>>>>>> SwingDisplayWindow(Window).dispatchEventImpl(AWTEvent) >>>>>>>>>>>>>>>>>>> line: 2478 >>>>>>>>>>>>>>>>>>> SwingDisplayWindow(Component).dispatchEvent(AWTEvent) >>>>>>>>>>>>>>>>>>> line: 4460 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> DefaultKeyboardFocusManager(KeyboardFocusManager).redispatchEvent(Component, >>>>>>>>>>>>>>>>>>> AWTEvent) line: 1850 >>>>>>>>>>>>>>>>>>> DefaultKeyboardFocusManager.typeAheadAssertions(Component, >>>>>>>>>>>>>>>>>>> AWTEvent) line: 910 >>>>>>>>>>>>>>>>>>> DefaultKeyboardFocusManager.dispatchEvent(AWTEvent) >>>>>>>>>>>>>>>>>>> line: 409 >>>>>>>>>>>>>>>>>>> SwingDisplayWindow(Component).dispatchEventImpl(AWTEvent) >>>>>>>>>>>>>>>>>>> line: 4502 >>>>>>>>>>>>>>>>>>> SwingDisplayWindow(Container).dispatchEventImpl(AWTEvent) >>>>>>>>>>>>>>>>>>> line: 2099 >>>>>>>>>>>>>>>>>>> SwingDisplayWindow(Window).dispatchEventImpl(AWTEvent) >>>>>>>>>>>>>>>>>>> line: 2478 >>>>>>>>>>>>>>>>>>> SwingDisplayWindow(Component).dispatchEvent(AWTEvent) >>>>>>>>>>>>>>>>>>> line: 4460 >>>>>>>>>>>>>>>>>>> EventQueue.dispatchEvent(AWTEvent) line: 599 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> DefaultKeyboardFocusManager$DefaultKeyboardFocusManagerSentEvent(SentEvent).dispatch() >>>>>>>>>>>>>>>>>>> line: 55 >>>>>>>>>>>>>>>>>>> DefaultKeyboardFocusManager$DefaultKeyboardFocusManagerSentEvent.dispatch() >>>>>>>>>>>>>>>>>>> line: 183 >>>>>>>>>>>>>>>>>>> DefaultKeyboardFocusManager.sendMessage(Component, >>>>>>>>>>>>>>>>>>> AWTEvent) line: 210 >>>>>>>>>>>>>>>>>>> DefaultKeyboardFocusManager.dispatchEvent(AWTEvent) >>>>>>>>>>>>>>>>>>> line: 286 >>>>>>>>>>>>>>>>>>> SwingDisplayWindow(Component).dispatchEventImpl(AWTEvent) >>>>>>>>>>>>>>>>>>> line: 4502 >>>>>>>>>>>>>>>>>>> SwingDisplayWindow(Container).dispatchEventImpl(AWTEvent) >>>>>>>>>>>>>>>>>>> line: 2099 >>>>>>>>>>>>>>>>>>> SwingDisplayWindow(Window).dispatchEventImpl(AWTEvent) >>>>>>>>>>>>>>>>>>> line: 2478 >>>>>>>>>>>>>>>>>>> SwingDisplayWindow(Component).dispatchEvent(AWTEvent) >>>>>>>>>>>>>>>>>>> line: 4460 >>>>>>>>>>>>>>>>>>> EventQueue.dispatchEvent(AWTEvent) line: 599 >>>>>>>>>>>>>>>>>>> SequencedEvent.dispatch() line: 101 >>>>>>>>>>>>>>>>>>> EventQueue.dispatchEvent(AWTEvent) line: 597 >>>>>>>>>>>>>>>>>>> EventDispatchThread.pumpOneEventForFilters(int) line: 269 >>>>>>>>>>>>>>>>>>> EventDispatchThread.pumpEventsForFilter(int, >>>>>>>>>>>>>>>>>>> Conditional, EventFilter) line: 184 >>>>>>>>>>>>>>>>>>> EventDispatchThread.pumpEventsForHierarchy(int, >>>>>>>>>>>>>>>>>>> Conditional, Component) line: 174 >>>>>>>>>>>>>>>>>>> EventDispatchThread.pumpEvents(int, Conditional) line: >>>>>>>>>>>>>>>>>>> 169 >>>>>>>>>>>>>>>>>>> EventDispatchThread.pumpEvents(Conditional) line: 161 >>>>>>>>>>>>>>>>>>> EventDispatchThread.run() line: 122 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thread [SciJava-4b2922f6-Thread-27] (Suspended) >>>>>>>>>>>>>>>>>>> Object.wait(long) line: not available [native method] >>>>>>>>>>>>>>>>>>> EventQueue$1AWTInvocationLock(Object).wait() line: 485 >>>>>>>>>>>>>>>>>>> Waiting >>>>>>>>>>>>>>>>>>> for AWT event thread to read invocation request. >>>>>>>>>>>>>>>>>>> EventQueue.invokeAndWait(Runnable) line: 993 >>>>>>>>>>>>>>>>>>> DefaultThreadService.invoke(Runnable) line: 95 >>>>>>>>>>>>>>>>>>> DefaultEventBus.publishNow(Object, String, Object, >>>>>>>>>>>>>>>>>>> List, List, StackTraceElement[]) line: 195 >>>>>>>>>>>>>>>>>>> DefaultEventBus.publishNow(Object) line: 86 >>>>>>>>>>>>>>>>>>> DefaultEventService.publish(E) line: 95 >>>>>>>>>>>>>>>>>>> DefaultStatusService.showStatus(int, int, String) line: >>>>>>>>>>>>>>>>>>> 77 >>>>>>>>>>>>>>>>>>> DefaultMinMaxMethod<T>.report() line: 296 >>>>>>>>>>>>>>>>>>> DefaultMinMaxMethod<T>.process() line: 155 >>>>>>>>>>>>>>>>>>> DefaultAutoscaleMethod<T>.getRange(IterableInterval<T>) >>>>>>>>>>>>>>>>>>> line: 70 >>>>>>>>>>>>>>>>>>> DefaultAutoscaleService.getDefaultIntervalRange(IterableInterval<RealType<?>>) >>>>>>>>>>>>>>>>>>> line: 97 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> DefaultAutoscaleService.getDefaultRandomAccessRange(RandomAccessibleInterval<RealType<?>>) >>>>>>>>>>>>>>>>>>> line: 105 >>>>>>>>>>>>>>>>>>> DefaultDatasetView.autoscale(int) line: 176 >>>>>>>>>>>>>>>>>>> DefaultDatasetView.initializeView(boolean) line: 499 >>>>>>>>>>>>>>>>>>> DefaultDatasetView.rebuild() line: 383 Takes the >>>>>>>>>>>>>>>>>>> DefaultDatasetView lock. >>>>>>>>>>>>>>>>>>> DefaultImageDisplay.rebuild() line: 140 >>>>>>>>>>>>>>>>>>> DefaultImageDisplay.display(Object) line: 273 >>>>>>>>>>>>>>>>>>> DefaultOverlayService.addOverlays(ImageDisplay, >>>>>>>>>>>>>>>>>>> List<Overlay>) line: 148 >>>>>>>>>>>>>>>>>>> TurboRegRegister.run() line: 144 >>>>>>>>>>>>>>>>>>> CommandModule.run() line: 196 >>>>>>>>>>>>>>>>>>> ModuleRunner.run() line: 168 >>>>>>>>>>>>>>>>>>> ModuleRunner.call() line: 129 >>>>>>>>>>>>>>>>>>> ModuleRunner.call() line: 1 >>>>>>>>>>>>>>>>>>> FutureTask$Sync.innerRun() line: 303 >>>>>>>>>>>>>>>>>>> FutureTask<V>.run() line: 138 >>>>>>>>>>>>>>>>>>> ThreadPoolExecutor$Worker.runTask(Runnable) line: 886 >>>>>>>>>>>>>>>>>>> ThreadPoolExecutor$Worker.run() line: 908 >>>>>>>>>>>>>>>>>>> Thread.run() line: 662 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>> ImageJ-devel mailing list >>>>>>>>>>>>>>>>>>> ImageJ-devel@imagej.net >>>>>>>>>>>>>>>>>>> http://imagej.net/mailman/listinfo/imagej-devel >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> ImageJ-devel mailing list >>>> ImageJ-devel@imagej.net >>>> http://imagej.net/mailman/listinfo/imagej-devel >>>> >>>> >>> >> >
_______________________________________________ ImageJ-devel mailing list ImageJ-devel@imagej.net http://imagej.net/mailman/listinfo/imagej-devel
