On Wednesday, October 9, 2002, at 03:51 AM, Nickolay Samofatov wrote:

> Hello Ann,
>
> Wednesday, October 09, 2002, 4:37:49 AM, you wrote:
>
>> At 12:57 AM 10/9/2002 +0400, Nickolay Samofatov wrote:
>
>>> There are ways of efficent interprocess communication.
>>> Have you read Linux or WinNT kernel specs ?
>
>> No, I haven't. The overwhelming problem with communication
>> in the classic architecture, at least in my experience, is
>> not the cost of IPC, but the cost of making it work on all
>> the variants that appear in such disparate operating
>> systems as Xenix, VMS, AIX, SCO, the Cobalt subset of Unix
>> et al. If we limit ourselves to Windows, Linux, and MacOS,
>> maybe that problem goes away.
>
> FB2 already dropped support for obsolete systems. Windows, Linux,
> and Darwin are not only modern systems out there. AIX supports rich
> IPC API too.

And I'm sure Solaris does too. FB has already dropped support for
them, but changing the architecture so they _can't_ be supported is a
different issue. That said, I think efficient IPC is a reasonable
requirement for a database server. And if designed in advance it may
well be possible to build a version of the server that doesn't use IPC
at all, but has some functional limitation. This would allow us to
support other "less modern" platforms in a more limited fashion if
there was a need.

>
>>> [...]
>
>>> What I think needs to be done is to start from CS and make
>>> it use resources better (and minimize syscalls). Then
>>> analyze its code to make it thread-safe and rewrite
>>> y-valve using SS code as an example to implement
>>> multi-threaded multi-process model.
>
>> Could you explain multi-threaded multi-process a bit more?
>> Currently that's an either/or choice. I can imaging a multi-
>> threaded version of classic that keeps the process per
>> connection but adds separate threads to allow parallel I/O
>> operations, sorts, etc. Is that what you mean?
>
> No. The way like Oracle Threaded Server works.
> There is a pool of worker threads distributed among of pool of
> processes.
> Connection context is allocated for each connection.
> Connection context is a simple data object which can be swapped out to
> the disk, for example. It doesn't consume resources by itself.
> There is a listener process (process pool, in fact) which handles
> incoming requests and distribute them between worker processes.
> When user request arrives request and connection context gets assigned
> to a worker thread which does its work and posts finished work so
> listener can return it to the consumer.
> I didn't describe some details - there are some optimizations to
> minimize
> context switches and context rebinding. Dynamic context binding is
> recommended by Oracle only when number of connections is really large
> >>100.

I'm not familiar with the Oracle model, but I too am thinking about a
multi-process multi-threaded model. The basic idea is the "server"
consists of one or more processes. These processes in turn consist of
one or (more probably) more threads. Depending on the actual site
configuration, installations might range from single process for all
attachments (much like SS is now) to a single process per database to a
single process for each attachment (like CS now). Most importantly the
engine code needs to be the same in all cases (not the SS ifdef's we
have now). Through the use of exclusive DB locks we should be able to
add performance optimizations for the SS-style installation while
retaining the multi-process functionality.

> [..big snip..]

It seems to me we need to (more or less) decide on the target
architecture before we can make intelligent decisions on how to make it
happen. For example, if our final goal is really just a "better" SS,
then it may well be foolish to ignore all the work that has already
gone in to making SS what it is. But in the same vein if our goal is a
multi-processes model it may well be foolish to ignore all the work
that has gone in to classic.

-John