## 8.6 Multi-threaded mixed C and Prolog applications

All foreign-code linked to the multi-threading version of SWI-Prolog should be thread-safe (reentrant) or guarded in Prolog using with_mutex/2 from simultaneous access from multiple Prolog threads. If you want to write mixed multi-threaded C and Prolog application you should first familiarise yourself with writing multi-threaded applications in C (C++).

If you are using SWI-Prolog as an embedded engine in a multi-threaded application you can access the Prolog engine from multiple threads by creating an engine in each thread from which you call Prolog. Without creating an engine, a thread can only use functions that do not use the `term_t` type (for example PL_new_atom()).

The system supports two models. Section 8.6.1 describes the original one-to-one mapping. In this schema a native thread attaches a Prolog thread if it needs to call Prolog and detaches is when finished, as opposed to the model from section 8.6.2 where threads temporary use a Prolog engine.

Please note that the interface below will only work if threading in your application is based on the same thread-library as used to compile SWI-Prolog.

### 8.6.1 A Prolog thread for each native thread (one-to-one)

In the one-to-one model, the thread that called PL_initialise() has a Prolog engine attached. If another C-thread in the system wishes to call Prolog it must first attach an engine using PL_thread_attach_engine() and call PL_thread_destroy_engine() after all Prolog work is finished. This model is especially suitable with long running threads that need to do Prolog work regularly. See section 8.6.2 for the alternative many-to-many model.

int PL_thread_self()
  Returns the integer Prolog identifier of the engine or -1 if the calling thread has no Prolog engine. This function is also provided in the single-threaded version of SWI-Prolog, where it returns -2.
int PL_thread_attach_engine(const PL_thread_attr_t *attr)
  Creates a new Prolog engine in the calling thread. If the calling thread already has an engine the reference count of the engine is incremented. The attr argument can be `NULL` to create a thread with default attributes. Otherwise it is a pointer to a structure with the definition below. For any field with value `0', the default is used. The `cancel` field may be filled with a pointer to a function that is called when PL_cleanup() terminates the running Prolog engines. If this function is not present or returns `FALSE` pthread_cancel() is used.

      typedef struct
      { unsigned long     local_size;    /* Stack sizes (K-bytes) */
        unsigned long     global_size;
        unsigned long     trail_size;
        unsigned long     argument_size;
        char *            alias;         /* alias name */
        int              (*cancel)(int thread);
      } PL_thread_attr_t;

  The structure may be destroyed after PL_thread_attach_engine() has returned. On success it returns the Prolog identifier for the thread (as returned by PL_thread_self()). If an error occurs, -1 is returned. If this Prolog is not compiled for multi-threading, -2 is returned.

int PL_thread_destroy_engine()
  Destroy the Prolog engine in the calling thread. Only takes effect if PL_thread_destroy_engine() is called as many times as PL_thread_attach_engine() in this thread. Returns `TRUE` on success and `FALSE` if the calling thread has no engine or this Prolog does not support threads.

  Please note that construction and destruction of engines are relatively expensive operations. Only destroy an engine if performance is not critical and memory is a critical resource.

int PL_thread_at_exit(void (*function)(void *), void *closure, int global)
  Register a handle to be called as the Prolog engine is destroyed. The handler function is called with one `void *` argument holding closure. If global is `TRUE`, the handler is installed for all threads. Globally installed handlers are executed after the thread-local handlers. If the handler is installed local for the current thread only (global == `FALSE`) it is stored in the same FIFO queue as used by thread_at_exit/1.

### 8.6.2 Pooling Prolog engines (many-to-many)

In this model Prolog engines live as entities that are independent from threads. If a thread needs to call Prolog it takes one of the engines from the pool and returns the engine when done. This model is suitable in the following identified cases:

- Compatibility with the single-threaded version
  In the single-threaded version, foreign threads must serialise access the one and only thread engine. Functions from this section allow sharing one engine among multiple threads.

- Many native threads with infrequent Prolog work
  Prolog threads are expensive in terms of memory and time to create and destroy them. Systems that use a large number of threads that only infrequently need to call Prolog are better take an engine from a pool and return it there.

- Prolog status must be handed to another thread
  This situation has been identified by Uwe Lesta when creating a .NET interface for SWI-Prolog. .NET distributes work for active internet connection over a pool of threads. If a Prolog engine contains state for a connection, it must be possible to detach the engine from a thread and re-attach it to another thread handling the same connection.

PL_engine_t PL_create_engine(PL_thread_attr_t *attributes)
  Create a new Prolog engine. attributes is described with PL_thread_attach_engine(). Any thread can make this call after PL_initialise() returned success. The returned engine is not attached to any thread and lives until PL_destroy_engine() is used on the returned handle.

  In the single-threaded version this call always returns `NULL`, indicating failure.

int PL_destroy_engine(PL_engine_t e)
  Destroy the given engine. Destroying an engine is only allowed if the engine is not attached to any thread or attached to the calling thread. On success this function returns `TRUE`, on failure the return value is `FALSE`.
int PL_set_engine(PL_engine_t engine, PL_engine_t *old)
  Make the calling thread ready to use engine. If old is non-`NULL` the current engine associated with the calling thread is stored at the given location. If engine equals `PL_ENGINE_MAIN` the initial engine is attached to the calling thread. If engine is `PL_ENGINE_CURRENT` the engine is not changed. This can be used to query the current engine. This call returns `PL_ENGINE_SET` if the engine was switched successfully, `PL_ENGINE_INVAL` if engine is not a valid engine handle and `PL_ENGINE_INUSE` if the engine is currently in use by another thread.

  Engines can be changed at any time. For example, it is allowed to select an engine to initiate a Prolog goal, detach it and at a later moment execute the goal from another thread. Note however that the `term_t`, `qid_t` and `fid_t` types are interpreted relative to the engine for which they are created. Behaviour when passing one of these types from one engine to another is undefined.

  In the single-threaded version this call only succeeds if engine refers to the main engine.

#### 8.6.2.1 Engines in single-threaded SWI-Prolog

In theory it is possible to port the API of section 8.6.2 to the single-threaded version of SWI-Prolog. This allows C-programs to control multiple Prolog engines concurrently. This has not yet been realised.