Jason Dodson wrote:

> I havent looked THAT deeply at the code, but it appeared to me that
> SuperServer was what seemed to be an application wrapped around the
> classic server implementation.

Would that it were that simple. Classic was single threaded, but
process based so it runs on multi-processors using a shared memory lock
table to coordinate page-level concurrency. SuperServer is
multi-threaded but uses its own thread scheduler in such a way that only
one thread is active in shared regions of the server. That works very
badly on SMP systems. They're both built out of the same code base with
conditional code paper over the differences in threading and concurrent
access control.

> It would be nice to have multiprocessor support.

We've got a variant called Vulcan, not yet ready for prime time, that
reworks Classic to be a multi-threaded engine and streamlines the server
to be a an application layered on the engine. Vulcan runs either
thread-based or process-based. In the thread-based model, all
connections are made through a library that maintains a shared page
cache and coordinates page access to insure database consistency. In
the process-based model, each connection is its own process and
maintains its own page cache. Physical database consistency is
maintained with a shared memory lock manager.

> THen using Firebird on something like Mosix or OpenSSI would be
> especially useful.

Actually, classic was designed for a cluster environment - VAXClusters -
with a distributed lock manager. That distributed lock manager is one
of the models for IBM's DLM and the model for the lock manager our
Classic implementation now uses. With money and hardware, we could
probably get classic running on Mosix/SSI/DLM reasonably quickly.

Regards,


Ann