Re: State Threads

[Ole-Hjalmar Kristensen <ole-hjalmar.kristensen@substitute_employer_here.com>]

>>>>> "WN" == Wojtek Narczynski <wojtek@power.com.pl> writes:

    WN> Hello,
    >> I've seen plenty of information and indication that C does not 
    >> outperform Ada significantly or at all.

    WN> You merely scratch the subject. How exactly would you structure an Ada
    WN> application to handle 100K socket connections?

One (very old) way of doing this is the way it has tradionally been
done in TP monitors. You have a pool of servers for each server class.
In case you only want to have a web server, you just need one pool.
The number of servers (threads) are dependent on you number of CPU's.
Typically you want some more threads than CPU's to account for threads
that may be blocking on IO. If you want to be fancy (TP systems are),
you can include a load balancer which creates new server threads in
case some of you CPU's are idle although there are unprocessed
messages, otherwise just have a reasonable number of threads in
reserve. All threads are identical, and execute in an endless loop,
consuming messages from the network. When the message is read, the
thread restores the execution context, in a TP system it would be the
transaction state, in a web server it would be the session state.  It
then dispatches on the message type, and executes in the restored
context. When it is finished, it sends the result. This model has no
problems with blocking on disk IO, because if a thread needs to block,
it blocks, and some other thread gets to execute. As long as there are
enough threads, no CPU will be idle. Since we dimension the number of
threads after the number of CPU's not after the number of connections,
there should be no thrashing. Now, this model is probably closer to an
event driven model than you like, but you do not need to register any
callbacks. The two critical points with this scheme are fast retrieval
of messages from the network and fast restoration of the execution
context. On a Unix system the select or poll system calls would be the
natural choiche to handle your sockets, although I wonder how it would
scale to 100K connections. The execution context takes the place of
the stack in state-threads, whether one is better than the other
depends on the application, I would think. Also observe that the
state-threads library has no explicit support for multiple CPU's.

You might argue that in a typical web server, each new request will
result in blocking disk IO, thus leading to an ever increasing number
of threads. But the answer is, just don't increase the number of
threads. If the disk is the bottleneck, increasing the number of
active requests will not give you any better throughput as long as you
have a reasonable number of active entries in the disk queue at any
time.

    >>> Also disappointing is the NIH syndrome that prevails the Ada world.

    >> No. We may be keen on 100% Ada, 0% bugs, but will use a good binding 
    >> happily. GtkAda, Pgsql...

    WN> Mercy. Without non-Ada code you could not even boot your computer, so
    WN> you are forced to use non-Ada code, it's not your choice.

    WN> Besides, this NIH syndrome is about reusing concepts, not about
    WN> reusing code.

    WN> Regards,
    WN> Wojtek

-- 
   C++: The power, elegance and simplicity of a hand grenade.