Workers never had the blessing of Paul Tarau [Prolog missed Web 2.0] (Was: C++ programming or a PhD in Macro defs)

Another solution would be to dismiss the whole Java
ClassLoader thing as humbug, and not strive for a
Knowlegebase abstraction, and create workers via some
operating system fork().
This might perfectly well work as well. It only
breaks down if you want to embed and integrate
your “workers”, into systems that have something like
this Java ClassLoader notion.
Either way, “workers” provide a nice new notion
besides engines, which was never covered by Papers
of Paul Tarau and the like, and might not have
existed in older Prolog systems. Because
old papers had a different ontology: Places,
Sandbox, etc.. workers were simply not on the radar.
The data isolation allows for non-cooperative
parallelism among workers, despite the notion of an
engine is rather cooperative. Workers got momentum
with Web 2.0 and early process isolation of browser
tabs in 2008 when Chrome debuted. Just after that
in 2010 they were introduced as part of HTML5 for
thread isolation inside a browser tab.
See for yourself:
Jinni: Intelligent Mobile Agent Programming
at the Intersection of Java and Prolog
https://www.researchgate.net/profile/Paul-Tarau/publication/2762429
Mild Shock schrieb:

If SWI-Prolog would be rewritten in C++ maybe a GLOBAL_LD
wouldn’t be needed at all. You could make Knowledgebase
and Engine classes, the C++ compiler would optimize for
 you passing around GD or LD in the form of a “this”, and
a method inside an Engine, could access a Knowledge base,
by “this->KB” or simply “KB”. C++ would be even less
annoying than Java, since you can do deferred mixin:
 class Person {
    [...]
}
 And later:
 void Person::Print() {
    [...]
}
 Because I don’t have deferred mixin in Java, my own
modularization looks extremly messy, passing around a
parameter explicitly, hoping that the usual register
file optimization of a Java compiler eliminates
 most parameter passing. But my C++ knowledge is very
limited, so I don’t know whether a PhD in Macro defs
was the better solution. Was there never a C++
 implemenation of SWI-Prolog ?
 Mild Shock schrieb:

>
 > The required changes could be fairly limited.
>
I don’t know. You never know before you did it.
With the current design you might end up in a
Münchhausen scenario, trying to defy gravity by
pulling your own hair. It seems there is a global switch
>
which engine is active? I don’t understand, isn’t
SWI-Prolog able to run truely concurrently on a
multi-core machine. Because such things, wouldn’t
work for threads that distribute themselves over cores.
>
I saw an L_THREAD lock somewhere?
>
#define GET_LD      PL_local_data_t *__PL_ld = GLOBAL_LD;
>
In the “worker” scenario, a “worker” can typically grab
a CPU core all for himself, and for its knowledge and
for all the engines that work over this knowlegde base.
Thats the beauty of JavaScript
>
isolation through “workers”, and it is also used in
the Ciao Playground. Its very multi core friendly, a
“worker” can also have its own garbage collection etc…
>
>
>
>