The Pear support was done before we contemplated read only CASes. Even though a CAS is read only, when you get Feature Structures (FSs) via iterating, those FSs are made into Java cover class instances, according to a) whether or not the JCas is being used, and if it is, b) what "set" of JCas cover classes is currently active.
Within a Pear, there can be different definitions of some JCas cover classes. The code "switches" the JCas set when crossing the Pear boundaries, as the pipeline is executing. This switching is not thread-safe. So (currently) a read-only CAS being operated on by thread T1 containing a Pear would switch to use the Pear's JCas definitions while perhaps another thread T2 not containing a pear, was iterating. This would (currently) cause T2 to start getting JCas cover class instances from the Pears's JCas definitions. Not sure how to proceed. On the one hand, we could keep Pear information on a "per thread" basis in thread local data. This perhaps might slow things down a bit (not sure). On the other hand, we could "outlaw" the use of Pears in read-only CAS situations (not sure how to detect this, though). It probably isn't a real problem (yet) because these are unusual ways to operate; I'm guessing that the applications doing shared read-only CASes are not using Pears, and vice versa (so far). Opinions welcomed :-) -Marshall
