[dev-serveez] Re: serveez

[stefan]

On Thu, 18 Mar 2004, Raimund 'Raimi' Jacob wrote:

> Brian S McQueen wrote:
>
> hello!
>
> > In particular I want to ask about coservers.  It looks like the design is
> > such that a coserver must return a single line of text.  One of my aims is
> > to have a separate standalone xslt template engine, which will accept xml,
> > and will return whatever is appropriate for the xslt.  With this idea in
> > mind, the web apps would produce simple xml output, and it seems that the
> > template engine would be ideally suited to be not only a full server
> > producing general output when given xml input, but also as a coserver,
> > handling the UI aspects of the web interaction, with no dependence on the
> > data generation phase, which could be something as simple as a CGI, or
> > something much more complex.
> >
> > Do I understand the server-coserver interaction correctly?  Why is the
> > coserver restricted to one-line text response?
>
> coservers are only used to do blocking calls in a non-blocking manner.
> for example: name resolution is provided by libc only in blocking class.
> since serveez' server loop must not be blocked, it let's a coserver call
> libc.

Yes.  This was the initial idea.

> for what you have in mind, i would strongly discourage you to use
> coservers. those coservers are more like an internal helper, not to be
> used for real work. you know, on the win32 platform the communication
> with the coserver doesnt work very well (IIRC), it will only pass data
> ever second or so.

Every select() or poll() timeout in fact.  If select/poll returns more
often (because of traffic in some server/client) coservers get more
responsive of the platform.  The reason is:  pipes in win32 can't be
select()'ed.

Serveez somehow ensures a certain number (configurable) of processes of
each type of coserver to run.  Another reason not to use coservers for
your purposes is:  It may occur that a coserver can't handle requests as
fast as sent to.  This dues to buffer overrun and serveez drops the
coserver and finally starts a new one of the coserver type it just killed
-> lossy flow of information.  Don't know whether you can afford that.
You may adjust this behaviour and enlarge the buffers initially or
dynamically.  And yet another reason not to use them:  If the serveez
server gets large in memory, the newly spawned coservers also increase...
possibly a waste of memory.

> for what you have in mind, you should implement something more like CGI.
> you might even use the CGI feature of the http-server. i imagine, that
> for performance reasons, you might want something like FastCGI (ie, the
> worker process does not terminate after handling a request, but rather
> waits for another). start a process, use pipes to connect it to the
> serveez server loop and pass around the data.

Another possibility is to use Guile's thread API.  Or implement both
communication ends as Guile servers (the Serveez supported ones).

I wonder how to decide...

Cheers,
        address@hidden