Warren Young: > That’s brand new code, less than a week old. It’s not surprising it’s > not rock-solid yet.
Yes, I agree, I no not expect complex new features to be flawless from the beginning. But I've stumbled into the issue while testing a fix from the current tip, and decided to report it early. > I expect drh is now on the case. :) 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.)? Maybe that these sub-processes concurrently try to "get the backoffice lease" after successfully serving their HTTP request, resulting in a race, and some of the sub-processes sleeping and waiting for 60 seconds for the lease to expire? I noticed the following commit: [a32a92d2] At the end of CGI processing, close the output pipe before starting backoffice processing, in order to let higher levels know that the CGI is finished. http://fossil-scm.org/index.html/info/a32a92d2 Maybe this fixed the same (or a similar) problem with the HTTP server on *nix, so the web browser quickly receives all the HTTP output, before the HTTP serving process is turning to backoffice work? But on Windows, g.httpOut seems to be a temporary file, and not a pipe, and the `fossil ui' main process may not be waiting for the file to become signaled when (any) I/O completes (which is a discouraged technique anyway), but for the sub-process that generated the file to exit? And this one sub-process sleeping is causing the delay in the `fossil ui' main process? Sorry for my prosaic speculation and no hard facts, but I find it all very interesting! Another minor point: The following line of source code from the aforementioned commit: g.httpOut = fossil_fopen("/dev/null", "wb"); always seems to result in g.httpOut==NULL on Windows, as "/dev/null" is not a valid Windows device. This probably doesn't matter from the logic of the code, as writing to a FILE* pointing to NULL may have exactly the same effect as writing to a FILE* pointing to "/dev/null"? --Florian _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
