6.5.4 Calling Prolog Asynchronously

If you wish to call Prolog back from a signal handler or a thread other than the thread that called SP_initialize(), that is, the main thread, then you cannot use SP_query() etc. directly. The call to Prolog has to be delayed until such time that the Prolog execution can accept an interrupt and the call has to be performed from the main thread (the Prolog execution thread). The function SP_event() serves this purpose, and installs the function func to be called from Prolog (in the main thread) when the execution can accept a callback.

A queue of functions, with corresponding arguments, is maintained; that is, if several calls to SP_event() occur before Prolog can accept an interrupt, then the functions are queued and executed in turn at the next possible opportunity. A func installed with SP_event() will not be called until SICStus is actually running. One way of ensuring that all pending functions installed with SP_event() are run is to call, from the main thread, some dummy goal, such as, SP_query_cut_fail(SP_predicate("true",0,"user")).

While SP_event() is safe to call from any thread, it is not safe to call from arbitrary signal handlers. If you want to call SP_event() when a signal is delivered, then you need to install your signal handler with SP_signal() (see below).

Note that SP_event() is one of the very few functions in the SICStus API that can safely be called from another thread than the main thread.