Ann W. Harrison wrote:

>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.
>
>

Does this mean that Vulcan has multiprocessor support?

Todd

>
>

[Non-text portions of this message have been removed]