On Sun, Aug 11, 2013 at 6:10 PM, Richard Hipp <d...@sqlite.org> wrote:
> On Sun, Aug 11, 2013 at 9:20 AM, Stephan Beal <sgb...@googlemail.com>wrote: > >> That wasn't terribly clear. FastCGI basically starts 1 instance of the >> app and keeps feeding it new data for each request. Fossil's structure does >> not allow it to do that. >> >> > Does too. > > For Fossil to run FastCGI/SCGI, all that is needed is another command > similar to "fossil server" or "fossil ui". The "fossil server" listens for > incoming HTTP requests and responds separately to each request. A "fossil > fastcgi" or "fossil scgi" command would do basically the same thing, except > that it would interpret the FastCGI or SCGI wire protocol rather than HTTP. > It _can_ do that but that negates the benefit of using fastcgi because fossil ends up forking anyway. > > Fossil does not support FastCGI or SCGI simply because I do not have ready > access to a webserver that supports those things and hence no way to test > any proposed implementation. There were 3 problems when i attempted a fastcgi port way back when (2009? 2010?): - FastCGI replaces read() and write() with its own "drop-in" replacements, so all code has to be compiled using them. However, they got the signature wrong on the write() routine. They take a non-const (void*) for the src argument), meaning that no compliant code can compile against it. - FastCGI wants to initialize fossil one time and keep piping new POST/GET data through it. Fossil's environment, IIRC, would potentially pollute one request with data from another since they were all sharing the same memory. - Because of the "singleton" behaviour, it was necessary to fork a new instance on each request, eliminating the benefit of fastcgi. -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
