Hello Jim,

Tuesday, October 15, 2002, 11:01:09 PM, you wrote:

<some harsh skipped>

> While were waiting for Mr. O'Donohue to explain connection management
> in a hybrid multi-thread/multi-process server, perhaps you could
> explain how the engine data structure's should have been designed?

Multi-thread/multi-process server is my idea and I really know how to
implement it. It is not effective when number of connections is small
or when users flood the server with a great number of very short
requests and system response time it the critical factor.
We'll get greater response time (because of increased number context
switches to serve a request), but total server performance will be
higher besause of decreased amount of overhead caused by large number
of scheduled threads or processes. OS's really begin to crawl if you
spawn several thousand threads or more.

We spawn one listener process per each interface/port/protocol we listen to.
It submits jobs to a pool of worker threads/processes and returns
results to a client when they are ready.

It seems to be good to have at least one worker process per cluster node,
but whether it should listen to incoming connections itself or listener
process should submit jobs to it should depend on the class of problems
system intended to solve.

My general idea is that server should be modular and flexible to allow
to work in different environments w/o recompilation or modification.

Dear Jim, your harsh remarks to Mark O'Donohue are a bit not correct.
He did really much to maintain Firebird code and he knows it pretty well.

> Jim Starkey

--
Best regards,
Nickolay Samofatov mailto:skidder@...