Hello,
I’d like to simulate a prolog “app” front end that asynchronously interacts with a prolog backend – in real life it would be via websockets – but for testing and simulation i am looking for something simpler.
I wonder what the simplest approach would be where interaction (via simple calls or messaging) is truly asynchronous but with minimal programming overhead.
Engines perhaps … or something simpler
thanks,
Dan
It is rather unclear to me what this means. Engines can be used for several things, but they are more for coroutines than asynchronous processing. Threads seem to be the most obvious solution. Notably Linux creates and destroys threads rather quickly. As for the communication, just create a socket or pipe and send messages as Prolog terms using write_canonical/2 and read/2. You can add a websocket layer on top of that, but Prolog terms already have a well defined message unit and thus that adds little. Otherwise, a websocket stream may be simply created on top of any Prolog stream (in addition to the conventional way to use HTTP with the UPGRADE method).
So, simplest is to have a thread that reads a message from a pipe/socket, and creates a thread to process it. Alternatively you send the message to a message queue and have a fixed pool of theads as “workers” that read the message and processes it. The thread does it’s work and writes the result to the other end of the pipe/socket. Multiple threads can write to the same stream without creating a mess, provided that you do so in a single write_term/3 or format/3 call.
Are you calling from Prolog to Prolog?
If it’s Javascript to Prolog, there’s sample code (with lots of awaits) here: GitHub - kamahen/swipl-server-js-client: Sample SWI-Prolog server with JavaScript client
(I’m thinking of updating this to also have a client in Prolog, now that there’s wasm support; but don’t know when I’ll have time to do that.)