#1 Thread safety

Francesco Garosi

The module lacks thread safety. It should be enabled at
least in order to avoid the CLIPS engine status to
become corrupted, but it would also be desirable that
operations on different Environments become possible to
concurrent threads.

The non-corruption safety should be implemented at the
lowest level; also the Python 'environment' objects
should implement an internal lock mechanism that is as
independent as possible from Python's GIL. At least
minimum latency should be ensured.


  • Logged In: YES

    Basic thread safety has been implemented as of version
    1.0_02 (CVS revision 1.6), although probably a more
    elaborate way to handle concurrent threads is still needed.
    Probably current operating mode could cause sometimes an
    excessive latency of the Python interpreter.

  • Logged In: YES

    The thread safety implemented in 1.0_02 is broken... it forces
    multithreaded applications to use high-level Python locks to
    make sure the CLIPS engine is safe. I think that the implicit
    thread safety, relying on bytecode instruction execution,
    should be enough for the first implementation of PyCLIPS.
    Version 1.0_03 will disable thread awareness by default.

  • Logged In: YES

    This request for feature or enhancement has been dropped: either
    it has not been considered useful, or inconsistent, or even its
    usefulness has not been considered worth the effort. Possibly
    other previously posted messages can explain the reason.

    Please post another RFE with title "Reopen RFE NNNNNN" (being
    NNNNNN the number of this RFE) and the reasons for reopening in
    the message body if you really think that the RFE has to be

  • Logged In: YES

    The implicit form of multithreading safety implemented by the
    Python interpreter should be sufficient at low
    level: "semantically" stronger forms of safety could be
    implemented by users of the high-level interface users.

    • status: open --> closed