On 7/22/18, Florian Balmer <florian.bal...@gmail.com> wrote: > > The Windows HTTP server (and thus `fossil ui') works by spawning > sub-processes for each individual HTTP request, right? This results in > multiple sub-processes per web page (one for the HTML page, one for > CSS, another one for JavaScript, etc.)? >
Every Fossil webpage is generated by a separate subprocess. This is true for Windows, Mac, Linux, BSD, whatever. And it is true regardless of how Fossil is launched. The backoffice is a facility to do background processing - things like sending email notifications, syncing with peers, maybe doing aggressive compaction of the repository - anything that is not directly interacting with the user. Backoffice runs after a webpage is generated, in the same subprocess. Once the entire webpage has been generated, Fossil closes the socket or file into which the webpage is being written, and then attempts to do backoffice processing. There can only be one backoffice process at a time, and another backoffice that is "on deck" - ready to run when the current one finishes. In most systems, the webserver returns results back to the user as soon as the output socket closes. So the user does not realize that the process that generated the webpage continues running for up to 60 seconds of backoffice work. But on Windows for "fossil ui" and "fossil server", the webpage is not returned to the user until the subprocess actually terminates. Hence, if the subprocess gets involves in backoffice work, that can delay the return of content to the user. The only comes up on Windows. I do not yet have a good work-around. -- D. Richard Hipp d...@sqlite.org _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
