Scryer-prolog: Architectural provisions for multiple threads

[triska]

Rust provides facilities for running multiple threads in parallel:

https://doc.rust-lang.org/1.30.0/book/second-edition/ch16-01-threads.html

Would it be possible to provide a Prolog predicate such as thread_create(Goal, ID) that runs Goal in its own thread, which can be waited for with thread_join(ID)?

If this is not possible at the moment, could you please take this into account in the architecture design of Scryer Prolog, to implement it in the future?

Especially web servers would benefit tremendously from being able to handle each client request in its dedicated thread.

Considering how such a predicate thread_create/2 could be implemented in the current code base may be an interesting issue for Rust programmers.

[pmoura]

See also the following standardization proposal for threads in Prolog:

threads.pdf

[mthom]

It will be a good challenge to implement a concurrent WAM that doesn't exact a cost to single-threaded programs. I'm not sure where to start. I have plenty of work ahead of me before I get near threads, though.

[triska]

One architecture that suggests itself is to equip each thread with its own dedicated WAM interpreter.

As a user who is interested in this feature, my expectation is not that the implementation of threads has no overhead. Rather, it would already be great if performance is sufficient to create interesting applications such as web servers. Even a very rudimentary implementation of threads would already suffice for interesting experiments for instance with Torbjörn Lager's Web Prolog.

It is completely understandable that other features have priority at the moment. I only hope that eventual multi-threading is taken into account in architectural decisions.

[matt2xu]

On a side note, as far as Web back-end programming is concerned, (OS) threads are not really considered useful anymore since most frameworks are using asynchronous I/O instead (Node.js of course, or in the Java world Vert.x, or Play in Scala, etc.). Erlang was a notorious precursor by supporting lightweight "threads" long before that (even though it took them a while to add support for multi-processor systems).

[triska]

Yes, to clarify: Certainly there does not need to be any kind of correspondence to OS-level threads at all, at least not necessarily.

For writing web servers in Prolog, all that matters is that there is a mechanism in place by which a goal that serves a client can be spawned off so that the main process can continue waiting for further connections, and dispatching them to their own dedicated handlers that run in parallel.