On Wed, May 29, 2013 at 10:09 AM, Stephan Beal <[email protected]>wrote:
> On Wed, May 29, 2013 at 3:59 PM, <[email protected]> wrote: > >> Despite my error, I find the simplicity of setting up a Fossil repo >> (or better a set of repos) under cgi fantastic. >> > > +1 > > @Richard: out of historical interest, what was the motivation behind > adding CGI support initially? (Despite CGI being archaic, it was _the_ > feature which caused my initial addiction to fossil.) > > Well, I suppose I don't consider CGI to be archaic. CGI is simple, concise, easy to administer, easy to implement (on both ends), efficient, and is supported by all web-servers (except nginx). CGI grows out of the historic development model where you spin up a new process to handle each specific task. Unix was built around this model. It is an older model, but just because it is old doesn't make it bad. There is really quite a lot to recommend it: (1) No need to worry about resource leaks because the operating-system automatically and efficiently reclaims resources when the short-lived working process dies. (2) Programming is much simpler because you can almost always run single-threaded and you can often get away with using global variables. (3) Unit testing and debugging is easier since the worker task is now an independent process that can be run from a command-line prompt and/or in gdb or valgrind. (4) Bugs in the application are well-contained. One worker task might segfault due to a bug, but other independent tasks continue happily running without impact. (5) There are no background processes that an administrator needs to monitor and keep running. The worker tasks are launched on-demand. Thus the administrative overhead is reduced. I'm not sure why the one-process-per-task model has fallen out of favor. One cause might be a quest to squeeze every last ounce of performance out of systems by avoiding the process creation and breakdown overhead. Another reason might be people growing up in a windows-oriented world where process creation and breakdown is significantly more complex and costly compared to unix where fork() and exit() are easy and cheap. I like things to have low administrative, development, and maintenance overhead. CGI fits that requirement nicely. Other similar technologies (FCGI or SCGI come first to mind) require a lot more effort to program, to set up, and to maintain. Those others might be slightly faster on a busy site, but CGI is "fast enough" for most applications, especially for small and light-weight applications. For something like Fossil, FCGI/SCGI would be no faster. (FCGI/SCGI might well be much faster if your CGI script starts with #!/usr/bin/perl or #!/usr/bin/php, but that is a function of the start-up overhead of your scripting language, not of the interprocess communication protocol. Fossil, being native code, starts up very quickly and so CGI startup time is minimized and the performance advantages of FCGI/SCGI are lost in the noise of the added complexity.) The Fossil and SQLite websites spin up about 4 or 5 new worker processes per second on a debian linux VM at Linode.com that is a 1/24th slice of an actual server. And yet the load average stays down around 5%. People say "Oh, you could go so much faster using $COOL_NEW_TECHNOLOGY". But I doubt it. And even if we could, with the load average holding steady at 5%, it isn't worth the trouble. Better to keep things simple and reliable. -- D. Richard Hipp [email protected]
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
