The server stack starts with a fork in ZnSingleThreadedServer>>start, then ZnSingleThreadedServer>>listenLoop initiates an infinite loop for serving requests calling ZnSingleThreadedServer>>serveConnectionOn: which forks off a separate thread to serve each request.

Presumably the Seaside is adaptor is called during the request handling ... where the transaction boundaries are managed.

There are basically four issues to consider:

1. Need to make sure that there is no persistent state being modified in the server stack above the Seaside transaction boundaries.
2. Install error handlers so that server errors can be logged and threads cleanly shutdown. Any unhandled errors in the server stack will terminate the gems.
3. Make ZnSingleThreadedServer>>start a blocking call. We want the server to be block so the outmost fork in ZnSingleThreadedServer>>start is unnecessary ... the repeat block in ZnSingleThreadedServer>>listenLoop is an effective blocking scheme.
4. With FastCGI, we discovered that at high request rates we could blow out memory with unrestricted accept/forks, so we need to probably introduce a limiter of some sort there.

Under load testing we should be able to flush out any other issues.