On Mon, Jan 25, 2010 at 02:48:26PM +0100, Jakub Narebski wrote: > Now those patches (mine and J.H. both) make gitweb use locking > (it is IIRC configurable in J.H. patch) to make only one process > generate the page if it is missing from cache, or is stale. Now > if it is missing, we have to wait until it is generated in full > before being able to show it to client. While it is possible to > "tee" output (using PerlIO::tee, or Capture::Tiny, or tie like > CGI::Cache) writing it simultaneously to browser and to cache for > the process that is generating data, it is as far as I understand > it impossible for processes which are waiting for data. Therefore > the need for "Generating..." page, so the user does not think that > web server hung or something, and is not generating output. Ah, ok, so the message is there to cover up for a technical problem. ;-) I didn't quite realize. Then, it would be great to tweak the mechanisms so that the user does not really have to wait. So, I wonder about two things: (i) How often does it happen that two requests for the same page are received? Has anyone measured it? Or is at least able to make a minimally educated guess? IOW, isn't this premature optimization? (ii) Can't the locked gitwebs do the equivalent of tail -f? P.S.: Again the disclaimer - if this is "too hard", it's better to accept patches like they are, then improve this later. But perhaps a better solution would be not to clutter the code by optimizing this case at all if it's not clear it really matters in the real world. Petr "Pasky" Baudis -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html