Ticket #868 (closed task: fixed)
Opened 2011-11-09T10:49:28-06:00
Last modified 2012-05-18T16:51:41-05:00
Verify waitForThreads() code in LegacyPlugin is safe
| Reported by: | bdezonia | Owned by: | bdezonia |
|---|---|---|---|
| Priority: | critical | Milestone: |
|
| Component: | Legacy Compatibility | Version: | |
| Severity: | serious | Keywords: | |
| Cc: | Blocked By: | ||
| Blocking: | #1011 |
Description
A second legacy plugin can be run while a first one is already running. Make sure the separate waitForThreads() calls in LegacyPlugin don't interact badly.
Imagine possible bad sequence:
- slow plugin started
- start second plugin which remembers orig threads
- slow plugin hatches new thread
- second plugin terminates and see new thread as its own and waits for it to terminate
A couple things:
- extra waiting might be the only bad side effect here
- each plugin records the active threads relative to the current thread's thread group. as long as each plugin is in its own threadgroup no problems should arise.
Change History
comment:1 Changed 2012-02-09T16:14:45-06:00 by bdezonia
- Priority changed from major to critical
- Milestone changed from imagej-2.0-beta2 to imagej-2.0-beta1
comment:2 Changed 2012-02-13T15:29:46-06:00 by bdezonia
CompileAndRun has been debugged and is working. Plugins that call other plugins work fine too.
The remaining tasks for this ticket are:
1) certainly add a method to lock the currently active Display/Dataset while it is being run through LegaycPlugin::run().
2) maybe find ways to detect thread termination quicker so that users aren't waiting on waitForThreads() so much. When loading Boats the plugin terminates a few seconds after the image is first displayed. Any changes the user makes in those three seconds can get lost or can interfere with the IJ1 plugin results.
comment:3 Changed 2012-02-15T15:35:41-06:00 by bdezonia
With a3ba7159826fbb9a60585340613d3cceb0782ef2 waitForThreads() performance greatly improved.
TODO
1) add a method to lock the currently active Display/Dataset while it is being run through LegaycPlugin::run().
2) have waitForThreads() code reviewed by someone else
comment:5 Changed 2012-03-05T11:21:10-06:00 by curtis
- Milestone changed from imagej-2.0-beta1 to imagej-2.0-beta2
comment:6 Changed 2012-03-13T13:55:43-05:00 by bdezonia
After some debugging I think this slow wait might apply in limited circumstances.
Opening Blobs takes a long time. Dumping thread info I see a number of Image Fetcher threads that are in a TIMED_WAITING state. I think the threads aren't closing due to some socket waiting or similar. Image Fetcher is nothing defined by IJ1, IJ2, ImgLib, or SCIFIO/BioFormats. It must be Java itself.
If you have a local copy of Blobs and you use the IJ1 version of File Open it loads nearly immediately and has an inverted lut too. We should determine what specific commands give long waiting times.
I've improved waitForPluginThreads() by whitelisting these Image Fetcher threads that are in a TIMED_WAITING state. This immediately improves Open Sample *. I believe this is safe. Changes present in e7ace4f02559cc404d64329d6c310cd8bc912e8f.
Putting print statements into LegacyPlugin:run() shows that it takes a very LONG time for waitForThreads() to return. Thus users can run other commands upon an image that looks loaded but in fact is not entirely harmonized. This causes some commands to fail.
Also some plugins hatch other plugins which may or may not work (like Compile And Run and others [the complicated version of Line Width...? Edit LUT ... ? these are guesses]).
So we really need to design a thread watching capability to LegacyPlugin that:
This is now a critical item.