Now launching a new campaign. Might take again
one year or so to complete. Whats the basic idea
here? Vey easy, perform a bifurcation on this here:

ISO/IEC DTR 13211–5:2007
Prolog multi-threading support
https://logtalk.org/plstd/threads.pdf

The main new objects and built-in predicates that
make then underlying concepts of coroutines and
workers visible are suggested as:

- call_later(Goal, Delay):
Borrowed from Python asyncio. Will create a stackless
coroutine. That will at least run after Delay
millisecond on top of the current task.

- create_task(Goal):
Borrowed from Python asyncio. Will create a stackfull
coroutine. That will run as soon as possible, in
a new task.

- create_worker(Path):
Borrowed from JavaScript. Will run the given Prolog
text in an a new Prolog processor. Communication with
the Prolog processor via asynchorous channels.

Why do this? Well to have the cake and eat it two.
Whats the cake here: A totally lockless and global variable
using Prolog system such as Dogelog Player.

And whats the additional benefit: Compensate that
the Prolog system is not freely threading. Allow
embarrassingly parallel via workers.

What are the chances and risks?

- Chances: Well lookless and global variable Prolog
system shows much higher performance. When we
compare Dogelog Player and formerly Jekejeke Prolog,
we see something like 3691 ms against 6339 ms.

Also coroutines offer the same comfort for
internet programming like threads. For example
using call_later/1 amazingly this here works:

Threads: SWI-Prolog

?- time(call_with_time_limit(0.5, sleep(1))).
% 20 inferences, 0.000 CPU in 0.507 seconds (0% CPU, Infinite Lips)
ERROR: Unhandled exception: Time limit exceeded

Coroutines: Dogelog Player for Java (works since today)

?- time(time_out(sleep(1000), 500)).
% Zeit 516 ms, GC 0 ms, Lips 308, Uhr 23.02.2024 14:05
Fehler: Ausführung abgebrochen da Zeitfrist abgelaufen.
user auf 2

- Risks: How bring this to all targets JavaScript, Python
and Java. JavaScript is obviously the simplest, since
it offers already Workers. But how about Python and
Java. Here some ideas:

Python: asyncio
We could view workers as process, and then use
the to_process() primitive call that already exists
in Python. Thus adding to workers to the existing
coroutines in Python.

Java: GraalVM
Java had already in the past so called isolates
http://apt.cs.manchester.ac.uk/intranet/csonly/jamaica/j2se_isolate-1_0-prd-spec/docs/java/lang/isolate/package-summary.html
Now they come up again:
https://medium.com/graalvm/isolates-and-compressed-references-more-flexible-and-efficient-memory-management-for-graalvm-a044cc50b67e

The article suggest also one might want to keep
a 32-bit implementation of a Prolog system,
64-bit are the bane of garbage collection.

Mild Shock schrieb:
> Now launching a new campaign. Might take again
> one year or so to complete. Whats the basic idea
> here? Vey easy, perform a bifurcation on this here:
>
> ISO/IEC DTR 13211–5:2007
> Prolog multi-threading support
> https://logtalk.org/plstd/threads.pdf
>
> The main new objects and built-in predicates that
> make then underlying concepts of coroutines and
> workers visible are suggested as:
>
> - call_later(Goal, Delay):
>   Borrowed from Python asyncio. Will create a stackless
>   coroutine. That will at least run after Delay
>   millisecond on top of the current task.
>
> - create_task(Goal):
>   Borrowed from Python asyncio. Will create a stackfull
>   coroutine. That will run as soon as possible, in
>   a new task.
>
> - create_worker(Path):
>   Borrowed from JavaScript. Will run the given Prolog
>   text in an a new Prolog processor. Communication with
>   the Prolog processor via asynchorous channels.
>
> Why do this? Well to have the cake and eat it two.
> Whats the cake here: A totally lockless and global variable
> using Prolog system such as Dogelog Player.
>
> And whats the additional benefit: Compensate that
> the Prolog system is not freely threading. Allow
> embarrassingly parallel via workers.
>

We still keep formerly Jekejeke Prolog on current
so that it has functionality to emulate Dogelog Player.
Now we have hit a spot, where we must rework it,

so that it also features task contexts. Interestingly
as a result this will also go down the drain.

Logic Engines as Interactors
Paul Tarau - 5 Aug 2008
https://arxiv.org/abs/0808.0556

The paper had lasting impact on SWI-Prolog, in that
they have an engines library. The impact on Jekejeke Prolog
was not that big. We demonstrated how to make an

interleaved call of an interpreters spun from an
interpreter. This was done by handcoding Java.
No engines library made it into our runtime library.

So in favor of coroutines we will discontinue
some designs that allowed piggy packed interpreters.
Besides that we expect that through channels,

- create_channel:
Will create an async channel for coroutine
communication. Thats the replacement of messages
queues from the threads world.

we can redo engines in case this would be needed.
We expect an emergent effect of synchronizity
since these channels just like coroutines,

should also work when single threaded.