Where SWI-Prolog support native preemptively scheduled threads that
exploit multiple cores, Python has a single interpreter that can switch
between native threads.7Actually,
you can create multiple Python interpreters. It is not yet clear to us
whether that can help improving on concurrency. Initially
the Python interpreter is associated with the thread that created it
which, for janus, is the first thread calling Python. The Prolog thread
that initiated Janus may terminate. This does not affect the embedded
Python interpreter and this interpreter may continue to be used from
other Prolog threads.
Janus ensures it holds the Python GIL when interacting with the
Python interpreter. If Python calls Prolog, the GIL is released using
Py_BEGIN_ALLOW_THREADS.
- Multiple Prolog threads can make calls to Python. The access to
Python is serialized. If a Prolog thread does not want other
threads to use Python it can use
py_with_gil/1.
When multiple Prolog threads make many calls to Python performance tends
to drop significantly.
- Multiple Python threads can make calls to Prolog. While Prolog is
working on the query, the Python interpreter may switch to other Python
threads.
Prolog may be called safely from any Python thread. The Prolog
execution is embraced with Py_BEGIN_ALLOW_THREADS and
Py_END_ALLOW_THREADS, which implies that Python is allowed
to switch to another thread while Prolog is doing its work.
If the calling Python thread is not the one that initiated Janus,
janus.query_once() and janus.query()
attach and detach a temporary Prolog engine using PL_thread_attach_engine()
and
PL_thread_destroy_engine(). This is relatively costly. In
addition we allow associating a Prolog engine persistently with the
calling thread.
- int janus.engine()
- Return the identifier of the Prolog engine associated to the current
thread, -1 if no engine is attached or -2 if this version of Prolog does
not support engines.
- int janus.attach_engine()
- Attach a Prolog engine to the current thread using
PL_thread_attach_engine(). On success, return the integer thread
id of the created Prolog engine.8The
current implementation passes
NULL to PL_thread_attach_engine().
Future versions may provide access to the creation attributes.
If the thread already has an engine the attach count is
incremented and the current engine id is returned. The engine is
detached after a matching number of calls to
janus.detach_engine()
- None janus.detach_engine()
- Decrement the attach count of the attached Prolog engine. Destroy
the engine if this count drops to zero. Raises an exception of the
calling thread is not attached to a Prolog engine.
In a threaded environment, Python calls must be guarded by
PyGILState_Ensure() and PyGILState_Release() that
ultimately lock/unlock a mutex. Unfortunately there is no
PyGILState_TryEnsure() and therefore we may create deadlocks when
Prolog locks are involved. This may either apply to explicit Prolog
locks from with_mutex/2
and friends or implicit locks on e.g. I/O streams. The classical
scenario is thread A holding the Python GIL and wanting to
call Prolog code that locks a mutex M, while thread
B holds M and wishes to make a Python call and
this tries to lock the GIL. The predicate py_gil_owner/1
can be used to help diagnosing such issues.
The current version as an integer can be accessed as
janus.version. The integer uses the same conventions as the
SWI-Prolog flag version and is defined as 10,000*Major
+ 100*Minor + Patch. In addition, the module defines the following
functions:
- str janus.version_str()
- Return the Janus version as a string Major.Minor.Patch.
- None janus.version()
- Print information about Janus and SWI-Prolog version.
