Threadable Interface for Ops about imagej-ops

[ctrueden]

Very sorry for the delay in replying here! I am finally getting close to caught up on things.

All in all, sounds like a very good idea!

My main question is: Is there a role for Functions which are not Threadable? My understanding from before was that you would make something a Function specifically so that it could be used in a multi-threaded way. What are the exceptions to this assumption?

If there are no exceptions, we could make Function itself extend Threadable (and AbstractFunction implement the Threadable API as you suggest) so that individual function implementations do not need to worry about it.

As an aside: adding an AbstractThreadable which provides a default getIndependentInstance() implementation would be quite easy: use reflection to copy all @Parameter field references. This would be sufficient as long as a deep copy of any parameter is not needed...

If there are potential exceptions to the "functions are threadable" rule, then I guess it's OK to have ThreadableFunction and ThreadableInPlaceFunction, since it provides flexibility (at the expense of names getting longer again).

For your example of Map as a Function which is not Threadable... is there some other reason that Map needs to be a Function at all, then? (I'm tired and not looking at the code right now, so apologies if this is obvious.) Because if there is no other value to Map being a Function, we could just stop implementing that interface and also clarify things the same way (i.e., not "nest the multi-threading too much" as you say).

[dscho]

@ctrueden I like the idea of making it easier for developers by making Functions extend Threadable.

Not so sure about the default implementation of getIndependentInstance()... do we really want to copy all @Parameter-annotated fields? I thought that the point was more that internal state is copied into a new instance, but that the parameters are then filled in in the individual threads?

[ctrueden]

FYI, I'll make a first effort at adding the Threadable interface either tonight or tomorrow.

[ctrueden]

@dietzc: Looking at the code now, I see that Map does not extend Function anyway, so you can't accidentally "over-parallelize"... can you?

[dietzc]

@ctrueden: Yes, this is what I meant! Actually one never can take a mapper, as it is not threadable at all. Like this we can avoid lot of nested multi-threading (which is nice). About the function: you are right. we can do this. I tried to think of a function which is not Threadable, but I can't think of one. So I think it's ok to let Function extend Threadable.

Thank you for taking care of this!

Christian

[ctrueden]

This issue is resolved as soon as PR #13 is reviewed and merged!

[ctrueden]

We merged it today, and released OPS 0.1.0!