[toronto-lisp] Some notes about this meeting

doug at hcsw.org doug at hcsw.org
Wed Nov 4 05:26:20 UTC 2009

Abram: Thanks for the really detailed notes. These are great.

Everyone else: Great meeting and thanks for showing up.

A couple remarks on the meeting minutes:

On Tue, Nov 03, 2009 at 10:56:41PM -0500 or thereabouts, Abram Hindle wrote:
> * Lisp Meet
>   - Java Dissambly
>   - 11 people
>   - SISC used for webapps
>     - weblocks for CL
>       - http://common-lisp.net/project/cl-weblocks/
>     - used tomcat to run SISC scripts
>   - composure in clojure (web framework)
>   - Doug Explains antiweb
>     - explains pre-forking
>     - antiweb pools processes

It's not pooling in the sense of thread pools. Typically there are a fixed
number of worker processes each of which can handle numerous connections with
very little memory/CPU. The incoming connections are fail-overed or round-robined
to these workers. We still need to write better docs on how to do all this but for
now start here:


>     - processes can have more than 1 connection
>     - goal: reliability
>     - process oriented
>       - hub
>         - route msgs
>       - logger
>       - priveledged port listening and transfering
>       - etc.
>     - transfer connections to other processes
>       - send filehandle over a socket
>       - domain sockets
>       - scmwrites
>         - sendmsg manpage

Sorry, that's SCM_RIGHTS. Also see the unix(7) and cmsg(3) manpages.
This is a very underappreciated feature of unix.

>     - doesn't proxy like ngix
>     - serves static content
>     - runs lisp for dynamic content
>     - claims it is easy to setup

You can judge for yourself:


Step 2 on that page can be replaced with:

git clone git://github.com/hoytech/antiweb.git
cd antiweb

That will download the bleeding edge. If you like you can checkout the
latest release (although we try to always keep master pretty stable):

git checkout antiweb-4.0BETA15

Let us know how we can make the installation procedure easier.

>     - db layer to be done
>       - bdb
>         - transactions

The DB layer works great as is. BerkeleyDB for in-process transactions
and CGIs for communicating with relational DBs. We would like to also support
asynchronous communication with relational DBs without needing to spawn off
CGI processes but we haven't needed to do this yet.

>     - for admins
>     - awp files
>       - like php
>       - caches


>       - lisp forms
>         - (page ...)
>         - compiled
>         - post handler and get handler do dynamic content..
>         - build http response
>           - give it headers etc.

Unfortunately the dynamic content features aren't documented well yet
because we expect it to evolve quite a bit more soon. The start of
documentation is here:


>     - cared about # of syscalls that responsed
>     - vish asked how to scale up to multiple installations
>       - not quite there yet
>       - ngix to dispatch to antiweb if you want it

This depends on what you want to do. It is "not there yet" because any
sort of scaling to multiple installations will require additional thought
and communication scripts. We already use multiple antiweb installations but
this is for fail-over reliability, not taking advantage of dispersed resources.
Nginx reverse-proxying to multiple antiweb installations works fine but you
will still need to consider and code for many scenarios no matter what webserver
you use or your particular requirements.

>     - supervisor processes

There is still some stuff I need to do to make supervisors more flexible.
I plan to do active worker monitoring in the next couple releases (though
as I described at the meeting running a cron every minute is working fine
for me now).


More information about the toronto-lisp mailing list