Hi Dan,
> I have my HTTP-based GUI but my process is going to do a bunch of
> stuff and it would be nice if the web server were still responsive.
Yes, this is the normal case, and works normally right out of the box if
certain rules are observed.
> The GUI will only display information about the status of the program
> and will be able to display information from the DB.
As you might have noticed, the response of a HTTP request by the GUI
always happens in a child process of the actual server. When the
function (app) is executed by that child process, it will stay alive as
an independent session. The server itself (the parent process) will
remain responsive.
The key to have many separate functionalities operate in an
application's context is that they are all children of the common parent
process. That parent process will synchronize the DB activities of all
children.
This is the case if these children are all separate GUI session, but
also if processes are explicitly forked by the application.
As Henrik mentioned, this might be achieved via the 'boss'
functionality, but this is not the most common case. More typical is to
have the main event loop (by convention typically set up in the 'go'
function) fork child processes upon certain events. Analog to the HTTP
events forking GUI child processes, other network/timer/pipe/whatever
events may trigger that.
> Would this be best handled by threading or through sharing a PicoLisp
> database? How is threading handled in PicoLisp?
Threading in the strict sense is not supported in PicoLisp. Either we
use child processes of a common family as described above, or
cooperative background tasks which are set up with the 'task' function.
The third possibility mentioned by Henrik, coroutines, are available
only in the 64-bit version, which I assume is not a probable option in
today's embedded systems.
The demo application (is it included in the OpenWRT distribution?) has
an example for background queries started in the 'go' function in
"app/main.l". This is a case where a connect on port 4040 triggers a
child process to handle such a query. It uses a 'task' in the parent
process that listens on the port, and takes care of the 'fork'ing.
Cheers,
- Alex
--
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
