Modeling threads in best portable way

[hnbeck]

Hi,

for this I'm refer to a short thread on Twitter

Prolog and Logtalk are great languages for data, knowlegde and other kinds of modelling. Now, at the moment I'm on a (basic) XMPP package for Logtalk. This would lead to model (here in the sense of "using") threads for handling incomming and outcomming XML streams. With SWI Prolog, you can write webservers and websockets with its thread pool. BUT: it is far from standardized and in no other Prolog available.

There is GraphStax and TerminusDB, both apps which seems to been (at least partly) developed in Logtalk. And I assume they need threads. So I'm asking myself (and you :) what is a good way to develop a complex system when starting in Logtalk.
is it:

1. Keep portable and use only the portable things in Logtalk to draw your application, meaning think single threaded and do such things like threads later in parts of the final app written in different languages?
2. Use the one Prolog fitting best your needs, independenly of portability, which allows thinking multithreaded from the beginning

My heart is with 1. from the perspective of an algorithm modeller, but would'nt that lead to difficulties with respect to draw a XMPP system?

Hm..... maybe I'm over-thinking here. I'm would be interested in your opinions :)

Cheers

Hans

[pmoura]

A clarification first. Graphstax sponsors Logtalk development; nothing more I can discuss publicly at this time. Regarding TerminusDB, I made several contributions to the project, notably bug reports, bug fixes, and application diagrams. Those contributions were made by applying Logtalk developer tools (e.g. the linter) to the TerminusDB code base. But the TerminusDB application itself doesn't use Logtalk AFAIK. They do use heavily Logtalk lambda expressions but via my yall library contribution to SWI-Prolog.

My general suggestion for developing Logtalk applications is to keep the implementation as portable as possible (e.g. always giving preference to Logtalk libraries) and to isolate as best of possible non-portable code in a well defined set of objects with well defined protocols.

[hnbeck]

Ah good to know, thanks for clarification. And your suggestion to implement as portable as possible sounds good. Objects, categories and protocols allow efficient grouping of "problematic" code.

Cheers

Hans