[ImageJ-devel] ModuleService.run

[Curtis Rueden]

Hi everyone,

Lee & I discussed a bit in the ImageJDev chat room, but for the benefit of
the list archives: this was done in several of today's commits:
r3682<http://dev.imagejdev.org/trac/imagej/changeset/3682>,
r3683 <http://dev.imagejdev.org/trac/imagej/changeset/3683>,
r3684<http://dev.imagejdev.org/trac/imagej/changeset/3684>,
r3685 <http://dev.imagejdev.org/trac/imagej/changeset/3685>,
r3686<http://dev.imagejdev.org/trac/imagej/changeset/3686>and
r3687 <http://dev.imagejdev.org/trac/imagej/changeset/3687>.

-Curtis

On Thu, Aug 11, 2011 at 2:50 PM, Lee Kamentsky <leek at broadinstitute.org>wrote:

> Hi Curtis, all,
> I'm looking at ModuleService.run and thinking of how to use it in
> CellProfiler. There's a comment:
> // TODO - Implement a better threading mechanism for launching modules.
> // Perhaps a ThreadService so that the UI can query currently
> // running modules and so forth?
>
> which is pretty relevant. I think that the natural thing to do would be to
> return java.util.concurrent.Future<**Map<String, Object>> which would be a
> future promising the map of outputs for the module. You'd wrap the
> ModuleRunner in a java.util.concurrent.Callable<**Map<String, Object>>
> instead of in a Runnable and use java.util.concurrent.**FutureTask to
> return the future.
>
> I like a programmatic style myself where you do things step-by-step instead
> of an event-driven style like a ThreadService. This would be great for
> scripting - you can imagine a script that executes a module, then, further
> down, gets the results from the execution. The script would proceed in
> parallel with the module execution and the additional boilerplate for
> threading would be minimal - just an additional call to Future.get() at the
> point where the result was needed.
>
> --Lee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20110812/2d191bae/attachment.html>