I have a project where I load and unload different user files using a Java service that communicates with SWI-Prolog using JPL.
In a typical service request the user wants to load a prolog file, then assert several facts and finally make a query. When the user finishes our service retracts the facts and unloads the file. However, we find that in the next service handling (serviced after the previous one has concluded) the file is still loaded and pollutes the query result.
Without details it is hard to tell. Different requests ending up on different threads might be a problem.
That said, if for each query you want to populate Prolog with a program and data, solve that and remove everything you might end up better without JPL, assembling a file, start Prolog, collect the result and be done.
An alternative approach is using in_temporary_module/3 from library(modules). It is a little fragile in the sense that you nicely have to obey its limitations or may end up with a crash. It does provide a means to quickly run a query on a temporarily loaded program without leaving traces. It is used by SWISH for isolating queries. SWISH also uses a dedicated thread for each query.
Isn’t this in principle a “worker”, as found in JavaScript.
Except maybe that it is less isolated. The temporary
modules can use shared libraries?
I always wondered whether below on C level, SWI-Prolog
has not only a concept of Engines, but also a concept of Knowledgebases? If you have a class Knowledgebase
you can also create a new worker, by first creating a new
knowledge base and then inside this knowledge base a
new engine, to run the worker. But sharing might be limited,
it depends how knowledge bases can be interlinked, maybe
invisible to the end-user, doing some caching tricks.