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:[email protected]?subject=unsubscribe
