Hi!

First of all, let me say that the code for the FCGI connector will
need to be changed!  Indeed, Netcgi prides itself on not having the
same limitations as the other libraries, in particular the
Sys.max_string_length limit.  But the FCGI module very much has it as
the entire input for a request is accumulated into a string!

I also believe the FCGI connector should support multiplexing of
requests since it is part of the spec.

Also, as a minor remark, the object [fcgi_out_channel] does not
protect against [#output ""] unwittingly closing the channel.

On Tue, 26 Apr 2005, Eric Stokes <gremlin@itkinetix.com> wrote:
> 
> As far as fastcgi's process model is concerned [...] managed by the
> web server [...] stand alone.  The common case is the first group
> [...]  A slight variation [...] create multiple threads within the
> same process, with each thread running a serv loop [...]

Ok -- several threads can share a given socket, even without a mutex.

> second group [...] My view is that if you are writing an application
> for which the concurrency models provided by the web server are not
> sufficient then you are more than likely working on a very big
> project, 

Let me strongly disagree with that.

For example, where I work, they will not be much keen to let me run a
script on the web server (because of security concerns and space
reasons).  Moreover, OCaml support for AIX has been dropped recently
IIRC so that would not be possible anyway.

> and would most certainly reject out of hand any kind of silly canned
> attempt at a server construction kit I could provide in ocamlnet.

Is this how you would characterize what JSERV offers? ;)

In any case, if the way JSERV handle concurrency models is good
enough, then I see no reason FCGI does not support that as well...
The ideal situation would be that a concurrency module be built on top
of a set of functions (through, say, a functor) for both FCGI and AJP.

> there is a lot of good documentation on the workings of fastcgi, and
> on building fastcgi applications in general. We try to implement a
> fastcgi connector that is close enough to the standard that that
> documentation is useful.

Yes and no.  The interface is fairly different from the ones in
e.g. C++ or Perl, so some doc on how to use it for multiprocesses /
multithreads is welcome.

Regards,
ChriS