Re: architecture recommendation about FOX (on Linux)

On 2026-05-11 13:28, Basile STARYNKEVITCH wrote:
> Hello from France,
> 
> I am on Debian Linux (Forky amd64) compiling the latest fox snapshot
> (1.7.89) of md5sum d49a1b144fa078559b7eaf5b2db8779e
> 
> I am also developing an inference engine (GPL licensed, C++ code) - see
> refpersys.org and github below.
> 
> That inference engine may run for a long time (e.g. hours), even if
> today (May 11, 2026) it does not.
> 
> So I need two "modes" for it: one with a graphical interface, and one
> without.
> 
> What is the prefered architecture fo such a thing? I am hesitating
> between:
> 
> 1. a FOX based process (conceptually short lived) which communicates
> with the inference engine (eg JSONRPC things). In some cases the FOX
> GUI process would compile temporary code (recieved on JSONRPC ....)
> into a short lived dlopened plugins.
> 
> 2. A single inference engine process which dlopen-s a FOX based shared
> libraries.

For something that runs that long, you may want to split into two
processes, and communicate through shared memory; your controlling
GUI can attach to the worker-bee process, or detach from it.

If you play your cards right, you can let the worker-bee continue to run
in the background even after you log out.

Depending on O.S. different synchronization methods may be required;
this is a bit different from the usual inter-thread primitives, as
you'll need special ones that can be referenced from different
processes [in other words, the O.S. must have a "name" for it
so your new process can find the other end of the IPC primitive.

This means pipes, local sockets, or System-V  semaphores, and on 
Windows,
NamedPipe, Event, Mutex, etc.



Just some hints.

   -- JVZ