On 24 Sep 2002 at 16:40, Dalton Calford wrote:

> Curiosity,
>
> Currently, superserver starts with the machine and only one copy runs,
> regardless of the number of databases on the machine, while classic
> starts at the time of connection, and again, runs a copy, ignoring the
> number of databases on the machine.
>
> What about a architecture that spawns like classic on the first
> connect to a database, operates like superserver (handling all future
> connections) and stays open until the last connection drops.
>
> The immediate benefits are
>
> 1) if you are developing test code on one database and kill the server
> process, you will not kill the process for other users 2) the first
> process spawned would put a physical lock on the file (limited by
> OS/filesystem structure) and if another process attempts to connect
> with a different path, a different SS process would start, try to open
> the file and fail due to the initial lock - this would be a way of
> preventing some of the corruption caused by invalid paths. 3) on
> multi-processor systems, you could specify the cpu the SS process per
> database would operate - this would give some benefits of multi-cpu
> threading.
>
> future design benefits may include
>
> a) the classic and superserver codebase to unify once again so it is a
> single offering b) shared disk/memory locking to allow for SS on
> clustered computing platforms c) short term patch until the code base
> is re-written to have the granularity needed for a SMP system.
>
> I agree with Ann in that having two diverging code/implementation
> paths is a death knell for the project, my suggestion is to merge both
> versus dropping one over the other......

The trick is, do modern clusters (like Beowulf) need separate processes, or do they
consider the cluster as being one big SMP type machine, and allow 3 threads to
work on three separate members of the cluster? In other words, is there still a
reason for a multi-process version of the engine to exist?






















Paul Schmidt, President
Tricat Technologies
paul@...
www.tricattechnologies.com