> > Again, no-one would be forced to parallelize anything if they did not want > to :) If the annotators are logically independent then there can be no > conflicts (which should be pretty clear based on their purpose - another > way of stating this is whether the order in which they are run matters or > not), apart from the kind of additional synchronization requirements I > already mentioned such as adding to the same list or incrementing a shared > counter. > What are the other ways that annotators can conflict with each other that > you had in mind? >
Primarily concerned with the index repository. First of all, I don't understand how multiple annotators could be iterating over an index that other annotators are modifying at the same time. Secondly, Marshall has spent much time making an index robust to inadvertent user changes. For example an annotator modifies some "key" feature values for an indexed FS, or [even impossible to know] modifies feature values that another annotator has used as keys in a custom index. These scenarios are now detected and automatically fixed under the covers, but both require looking across all indexes in all views at the same time. Allowing multiple annotators to operate R/W on a common index repository would preclude both automatic fixup and detection. > > In any case, the fact that it might be possible to use a function > incorrectly in general doesn't sound like a good reason to not support it. > The same could be said of pretty much anything (again the existence of the > low level API is one good example of this!) > True. It could be a choice to turn off index protection in order to run in multi-threaded mode. Eddie
