The CLIPS engine is a separate subsystem, as stated many times before. In other words, it maintains a state independently from what happens in the Python interpreter. This also means that, since CLIPS was never conceived to be used as a multithreaded library, multiple threads should not try to access the engine concurrently. The Python interpreter, due to its nature, does not actually allow concurrent calls to the low-level module, so it is safe to create concurrent threads that interact with PyCLIPS.
However this has the side effect that, during a time consuming task (such as calling Run() on a complex set of rules and facts) the calling thread may block the other ones.
A partial solution to this, to allow multiple threads to switch more
reactively, is to call Run() with the limit parameter,
which specifies the number of rules to be fired at once. Of course this
allows subsequent calls to the CLIPS engine to modify its state, and
consequently enables execution paths that could be different from the
ones that a full CLIPS
(run) would normally cause. Obviously
this only applies to the Run() function.
The consideration also implies that multithreaded Python applications should take care of examining the engine state before interacting with it, especially when splitting Run() (which normally modifies the state) in multiple calls.