Interface GeneratorQueryProvider

  • All Known Implementing Classes:
    QueryProviderBase

    public interface GeneratorQueryProvider
    Represents an API of QueriesGenerated using *Condition objects, source of the queries Callers can reuse condition objects obtained during current generation session. XXX It doesn't look right to pass SNode in there - when we deal with generated template code, there are hardly SNodes to pass around. OTOH, one may perceive this as front-end to generated queries for an interpreted code (which always possesses SNode), while generated code doesn't need this as it invokes queries directly (such approach, however, prevents us from using GQP as factory for augmented queries (e.g. trace/access recording)). Concurrency/parallel generation: 1. Now providers do not care about multi-threading/query reuse. It's caller responsibility, and some queries get cached e.g. reduction rules' conditions. Technically, for ReflectiveQueryProvider this means we shall take care about lazy method initialization in check/evaluate (e.g. if different threads try to evaluate same rule's condition at the same time) 2. It's not that relevant for non-reflective GQP, as they got nothing to load at the moment (pre-initialized at construction time) 3. QueryProviderCache doesn't cache reflective providers at the moment. Reflective providers are pure stateless factories, so access to a query object (here, get, not check/evaluate) need not be synchronized/guarded. 4. Once/if caching of ReflectiveQP is enabled, we shall address concurrency/parallel initialization issues. As long as each thread gets its own query instance, and this instances are not shared between threads, lazy init in evaluation couldn't break (although might duplicate some stuff in memory). 5. Perhaps, it shall not be QueryProviderCache to cache queries, but rather shared TemplateNode. Still, lazy init in evaluate() may yield concurrency errors. TemplateNode comes from TemplateProcessor, which seems to be 1 per step, so queries are reused between threads. 6. Besides TemplateNode, concern (1) is still valid (cached queries), we shall care about lazy evaluate() anyway and shall not wait for RQP caching?