Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
CamlGI question
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Michael Alexander Hamburg <hamburg@f...>
Subject: Re: [Caml-list] CamlGI question

On Tue, 19 Apr 2005, Christophe TROESTLER wrote:

> On Mon, 18 Apr 2005, Mike Hamburg <> wrote:
> >
> >
> I downloaded your files.  For a start, all the modules are -pack'ed
> into[x]a, so you only need to link with that file.  Also,
> the interface of the library is in camlGI.mli with complete
> documentation.  In particular, you should not use hidden submodules:
> e.g. in "", say [open CamlGI] and then [Cgi.HttpError] instead
> of [Cgi_types.HttpError].  Same in "": you should say [open
> CamlGI.Cgi], not [open Cgi].
> [Request.metavar rq.rq "SERVER_NAME"] can simply be replaced with
> [Request.server_name rq.rq]
> [cgi#header_was_emitted ()]: such method does not exist in the public
> interface.

It doesn't exist at all.  I added it because I was getting mysterious
type errors from OCaml when trying to compile directly.  It was on my
"things to clean up" list.

> I do not see why you set [rq=request] as the request can be gotten
> from the cgi object [cgi#request].

You're right, I missed that.

> > When used as a FastCGI, the indexing script hangs, [...] It is quite
> > clear that the script has finished by the time the hang occurs
> Do the examples provided with the lib work as they should?

I'll check that too (I'm not at home right now).

> Are you sure your [main] function actually terminates?  Indeed, the
> output is buffered (at least by CamlGI) and may not be fully outputted
> until the script finishes.  Also, if you wish to launch a new
> process/thread per request, be sure to use the [fork] optional
> parameter to [handle_requests ?fork f conn] -- otherwise [f] will
> return immediately and the output "channel" will be closed early.

My main function does actually terminate.  I put a logging message at the
end of the function.  And it's not just buffering output, as killing the
CGI script with signal 9 causes no truncation.  I'll set it to create a
new thread to handle the request, although that doesn't particularly
matter (the threading is necessary to keep the thumbnail cache running,
not for load issues).

> CamlGI follows closely the spec -- even the multiplexing part which is
> not implemented by many.
> > The plain CGI version works just fine
> CGI output is not buffered.
> > the features of the script only work in the FastCGI version, such as
> > thumbnailing.
> Why is that?  Do you need persistence for that?

I can do it without persistence, but synchronization is much more
difficult in that case, eg, preventing to processes from trying to
thumbnail the same files at the asme time.

> Hope it helps.  If it does not, send me an example (if possible
> minimal but definitely self-contained) that exhibits the undesired
> behavior and I'll have a look.

I'll work on it soon and figure out whether this helps or not.  Hopefully
it will.

> ChriS

Thanks a lot for your help,