Subject Re: [IB-Architect] Classic vs. superserver (long, very very long)
Author Ann W. Harrison
At 09:43 PM 10/8/2002 +0200, Pavel Cisar wrote:

>First, the classic is somewhat easier to port,

I've seen the evidence of that, but suspect that it has more
to do with the build procedures. Classic retained build
procedures from a time when InterBase ran on dozens of
platforms. Superserver started as a windows-only thing
and the builds we inherited ... I guess I don't have to
say more.

Classic is inherently less portable because it uses inter-
process communication and shared memory Until quite recently,
Unix/Posix had enough different ways of handling those that
most implementations were both compliant and incompatible.

>and we were not very lucky
>to make the super server work on some platforms.

As above - the threading primitives are simpler and and
more consistent than the combination of signals and
shared memory, so the problems are more from the build
(I think) than from the architecture.

>differences in implementation of threads among platforms make things

No doubt

>and it's very likely that SS will not be very reliable on some
>platforms until we find a resolution, while classic would just work for
>majority of users.


>Next, it's true that SS has better potential to scale, but only a
>fraction of users would benefit from it. Actually, one half of our
>current userbase use FB as a personal database or as a workgroup server
>up to ten simultaneous connections (all that mostly on Windows). While
>CS (as is now) is ideal for embedded solutions, SS (as is now) is an
>overkill for such solutions.

I guess no one would be surprised if I found the other half
of the user base more interesting. A shared server starts to
be a good thing at two users - the shared caches reduce the load
on the disk, which is our greatest bottleneck. For a single user
application, I suppose classic is OK, though the lock management
code is certainly overkill.

>So, although I would like to see only one architecture used (as anyone),
>it's definitely a long run, that would require another codebase split.

In my opinion (I should probably start every sentence with those
words, but that's also overkill), we'd be better off abandoning
the current classic architecture and putting our effort into
fixing the glaring problems with the server architecture, then
creating a subset, in-process library for embedded use.


We have answers.