How can I implement a callback to Prolog from Rust?

[aarroyoc]

I'm trying to integrate the Hyper Server backend into Scryer as part of the next generation http_server. However, it uses callbacks internally, so the best option seems to have a predicate callback in the Prolog side too that handles the request and the response, and call it from the Hyper callback. Something like this:

Rust:
Http::with_callback(|req|{
    // call prolog predicate `http_callback` with req, obtain res
    Ok(res)
});
Prolog:
http_callback(Req, Res) :-
    % manipulate Req and build Res

But I don't know exactly how to implement that kind of callback in Scryer. I've seen the execute_clause and related functions but I'm not sure if it's the right approach, nor the best way to push arguments. Some other questions are: what will happen when the callback finishes? How to recover from a callback back to normal execution? (maybe in this case we do not want to, and if you start http_server you're stuck forever in a HTTP loop but...)

[mthom]

You'd have to implement separate system instructions for issuing the request to the server and awaiting the response, both as a matter of the WAM's design philosophy and because the borrow checker won't allow you to do otherwise. A blocking request-and-wait could be implemented as a single instruction but a non-blocking request needs at least two.

Scryer is a direct threaded interpreter. As such, there is only one call stack frame belonging to dispatch_loop at any given time. Co-routining between Prolog and Rust is not really a thing, that is, a Rust function can never cede execution to dispatch_loop, let it run for a time, and then return to the point where the function yielded control to dispatch_loop. Instruction execution is totally atomic in the sense that it completely disallows this.

For example, TcpListener is an arena allocated type whose values are passed between different WAM instructions as a HeapCellValue using the Cons tag. Cons indirects into the arena where it's tagged as a TcpListener.

[aarroyoc]

A blocking request-and-wait is what I do in the HTTP client but for the server the Hyper API requires callbacks... If Hyper API allowed for iter-polling just like TcpListener does, I would have copied that but asking on Discord they told me they're not going to move from the callback based approach.
Now that I know that coroutining between Prolog and Rust is not possible, I'll try to find if I can create a wrapper using futures that internally works with events but exposes an iter-polling interface. Or move to another library but it's a shame because Hyper it's the most mature solution

[triska]

This may all become easier once #546 is addressed: If there were a way to spawn a thread, then that thread could simply wait for an event, and then perform the callback, while the main thread continues as usual.

[aarroyoc]

Yes, it not only became easier but probably more performant but I understand that task can take a long time. Right now I think I have found a way to use Hyper transforming the callbacks to Tokio mpsc channels.